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ABSTRACT 


With  the  introduction  of  formal  specification  of 
abstracted  computer  resources,  both  physical  and  logical, 
there  is  the  possibility  that  a  major  step  forward  can  be 
made  toward  developing  a  methodology  for  reducing  the 
portability  and  reusability  costs  of  computing  system 
components.  Still,  the  current  methodology  is  only  concerned 
with  the  static  functional  properties  of  resources  and  not 
their  timing  properties.  This  places  limitations  on  the 
generality  of  the  method.  This  study  describes  a  way  to 
formally  specify  the  timing  of  computer  systems  by  combining 
ideas  of  both  semantic  algebras  and  Petri  Nets. 
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Timing  in  computer  systems  has  been  a  critical  issue 
throughout  the  evolution  of  computers.  The  most  obvious  areas 
where  timing  is  of  great  concern  are  operating  systems, 
distributed  systems  and  real-time  systems.  In  the  most  other 
areas,  timing  of  a  computer  program  is  taken  for  granted 
since  we  assume  a  simple  sequential  execution  of  this 
program.  But  we  have  to  realize  that,  when  we  consider  the 
program  and  the  machine  on  which  it  has  to  run  as  a  whole, 
i.e.  a  computer  system,  we  have  to  deal  also  with  the 
internal  timing  of  the  hardware.  Even  though  high  level 
programming  languages  have  provided  us  with  the  means  to 
software  from  one  system  to  another,  we  still  find  these 
programs  may  not  work  properly  because  of  timing  problems. 
These  timing  problems  are  normally  caused  by  different 
implementations  of  computer  resources.  So  It  would  be  very 
helpful  to  have  a  way  of  comparing  computer  systems  and 
predicting  problems  in  timing  when  programs  are  transferred. 
It  would  even  be  much  better  to  have  specifications  of 
computer  systems  that  could  be  used  to  design  transf er rab 1 e 
programs  in  the  first  place. 

There  is  ongoing  research  at  the  Naval  Postgraduate 
School  on  the  formal  specifications  of  computer  systems  that 
is  mainly  intended  to  overcome  the  increasing  costs  of 


conputer  software  resulting  froa  problens  with  portability 
and  reusability  of  prograns.  The  first  result  of  this 
research  projecc  has  been  the  developaent  of  a  formal 
specification  methodology  by  Davis  (1984).  This  methodology 
was  successfully  used  to  write  a  formal  specification  of  an 
Abstract  Processor  by  Yurchak  (1984).'  This  work  was  followed 
by  several  extensions  of  the  Abstract  Processor  and  related 
work  by  Hunter  (1985)  and  Zang  (1985).  The  research  performed 
at  the  Naval  Postgraduate  School  is  part  of  a  relatively  new 
branch  of  computer  science:  the  Soienoe  of  Computing  System 
Design  which  is  concerned  with  a  formal  approach  to  the 
specification  and  description  of  computer  systems.  This 
thesis  follows  the  direction  of  previous  work  done  in  this 
field.  Its  objective  is  to  formally  specify  timing  in 
computer  systems.  Even  though  there  has  been  considerable 
interest  in  timing,  our  approach  will  emphasize  two  aspects 
of  the  problem: 

-  Ue  want  to  develop  a  formal  way  to  specify  timing  to 
achieve  the  benefits  of  the  rigorous  foundation  of  a 
formal  description. 

-  We  want  to  specify  abstracted  resources  which  include 
both  hardware  and  software  with  a  unified  approach. 

Throughout  this  thesis  the  term  "computer  resources"  is 

used  in  a  sense  that  combines  all  hardware  and  software 

building  blocks  of  computer  systems:  memory,  registers,  data 

types,  instructions,  etc..  Also  the  special  aspect  we  are 

'An  edited  version  of  the  specification  of  the  Abstract 
Processor  is  included  in  Appendix  A 
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concerned  with  is  tine  as  a  computer  resource.  Computer 
resources  can  be  either  pure  physical  or  they  can  be  an 
abstract  type.  A  memory  cell  belongs  to  the  physical  category 
while  a  specific  data  type  belongs  to  the  abstract  category. 
The  means  to  deal  with  these  differences  is  abstraction. 
Specifying  computer  resources  as  abstractions  in  a 
mathematical  way  also  allows  us  to  compare  different 
specifications  and  implementations. 

Within  this  work  we  will  emphasize  a  practical  viewpoint. 
Even  though  in  applying  pure  mathematical  concepts  to 
computer  systems  we  realize  that  computers  are  in  no  way 
ideal:  as  every  piece  of  hardware  is  finite  (especially  the 
memory)  and  an  event  in  the  computer  is  never  instantaneous 
but  will  take  a  certain  amount  of  time.  In  this  context,  for 
example,  the  term  "digital  computer"  is  misleading  since 
there  are  many  undefined  states  between  those  defined  "0"  and 
"1". 

Therefore  the  goal  of  this  thesis  is  to  provide  a 
methodology  for  the  rigorous  specification  of  timing: 

-  to  evaluate  the  time  behavior  of  systems  which  leads  to 
the  exhibition  of  possible  places  in  system  where 
parallelism  could  be  used, 

-  to  give  a  better  understanding  of  the  dynamic  aspect 
of  computer  resources  in  time,  and 

-  to  find  time  critical  situations  in  a  system. 


I  I .  BACKGROUND 


A.  FORMAL  SPECIFICATION 

The  idea  of  specifying  a  system  formally  is  to  deal  with 
physical  and  abstract  computer  resources  as  abstractions  to 
support  our  major  concerns  with  portability  and  reusability. 
In  this  sense  we  deal  with  computer  resources  as  abstractions 
which  we  want  to  describe  such  that  the  functions  and  the 
properties  of  a  resource  are  stated  in  a  mathematical  way  to 
support  precision  and  provability.  Studies  in  this  direction 
have  been  conducted  by  many  researchers  (Goguen  (1978), 
Guttag  (1978),  Bergstra  (1983),  and  Davis  (1984)).  As  a  short 
introduction  to  this  work  we  would  like  to  present  some  key 
issues  here  as  they  were  used  in  the  first  formal 
specification  of  the  Abstract  Processor. 

The  formal  specification  of  the  Abstract  Processor  is 
based  on  the  method  of  algebraic  specification  which  consists 
of  two  parts:  the  interface  specification  and  the  constraints 
specification.  The  interface  specification  declares  operands 
and  the  operators  that  can  be  applied  to  them,  so  information 
for  syntactic  constructions  and  type  checking  are  provided. 
The  constraints  specification  is  a  set  of  properties  that 
define  constraints  on  the  operations.  These  properties  are 
stated  by  equations  that  associate  the  same  meaning  to  pairs 


iipeci  f  ication  of  the  computer  resource  "boolean"  is  shown  in 
Figure  2. 1. 

Rmtourom  boolean  im 

Operands 

bool 

Operators 

not:  boo]  ->  bool] 
and:  boo J , bool  ~>  bool; 
true:  ->  bool; 
false:  ->  bool; 

Properties 

not(true( ) )  =  false(); 

not (not (x))  =  x; 

and ( true (), X )  =  x; 

and ( fa  1 se< } , X )  =  faJse<); 

end  boolean; 

Figure  2.1:  Specification  for  Resource  "boolean" 

Figure  2.1  illustrates  the  definition  of  one  operand  type 
(bool)  and  the  operations  (not,  and,  true,  false)  that  are 
allowed  with  this  operand.  The  operations  are  stated  as 
functions  with  their  input  and  output.  Note  here  that  the 
constants  resembling  "true"  and  "false"  are  obtained  from  the 
nullary  operator  functions  with  no  input  C"true()"  and 
"false()").  Up  to  this  point  only  the  interface  part  is 
considered.  The  meaning  of  the  specification  is  indirectly 
in  the  form  of  equations  that  state  that  certain  expressions 
must  be  treated  identically  to  other  expressions.  The  above 
equations  use  ”x"  as  a  free  variable,  i.e.  "x"  stands  for  any 


expression  that  can  represent  an  operand  of  type  "bool".  So 
far  this  computer  resource  "boolean"  is  an  abstract  data  type 
in  the  traditional  meaning.  But  computer  resources  also 


consists 

of 

physical 

resources  which 

are  very 

simi lar  to 

abstract 

data 

types 

in 

their  specification.  Figure  2.2 

provides 

an 

examp  1  e 

of 

specifying  a 

physlca 1 

computer 

resource 

to 

indicate 

the 

memory  state 

of  the 

Abstract 

Processor.  For  simplicity  only  the  operands  for 
initialization,  fetching  and  storing  are  presented.  The  first 
interesting  fact  to  note  in  this  specification  is  that  it 
states  that  the  resource  "amstate"  is  an  extension  of  the 
previously  defined  specifications  of  the  resources  "boolean", 
"memaddress" ,  and  "regaddress" ,  i.e.  all  operands,  operators, 
and  properties  defined  in  these  specifications  can  be  used  to 
specify  "amstate"  without  further  explanations.  The  operand 
"state"  has  in  this  example  four  operators  to  initialize  the 
processor,  to  fetch  from  memory  and  registers,  and  to  store 
to  memory  and  registers.  The  properties  for  these  operations 
are  shown  by  equations  that  indicate  their  relations  among 
them.  Note  that  this  example  uses  the  term  "undefined"  to 
indicate  an  error  or  don’t  care  condition  (the  attempt  to 
fetch  the  contents  of  an  register  or  memory  address  of  a  new 
initialized  processor  is  illegal). 

The  basic  step  in  becoming  familiar  with  formal 
specifications  is  to  consider  the  well-known  constructs  of 
abstract  data  types:  a  class  of  objects  together  with  a  set 


of  oporations  that  may  be  applied  to  these  objects.  This 
approach  can  also  be  applied  to  physical  conputer  resources. 


Rmmourom  mmstate  Jm 

Extanaion  of 
boo  I  man, 
mamaddrmss, 
rmgaddrasa, 

0pm rand a 
atatmi 

Opmratora 

fmtcha:  mmmaddr, state  val ; 
fetohr:  regaddr , state  ~>  val ; 
storem:  va 1 , memaddr,  state  ->  state; 
storer:  va I ,  regaddr ,  state  ->  state; 
initamz  ->  state; 

Properties 

fetchm(a,initam<))  is  undefined ; 
storem(fetchm<a,q),a,q)  *  9/ 
impt ies< eqmemaddr (al, a2), 

'  fetchm(ai ,  storem(v,  a2,  q)  )  *  v) 

-  trueO; 

impl ies( not (eqmemaddr (al  ,a2), 

fetchm(al ,  storem(v,  a2,  q)  )  -  tet^ 

-  true(); 


-  fetchm(al ,  q) ) 


fetchr(r,initam())  is  undefined; 
storer ( fetohr ( r,  q) ,  r,  q>  ®  q; 
imp] ies( eqregaddr (rl,  r2> , 

f etchr ( rl , storer ( V, r2,  q) )  -  v) 

-  trueO; 

i mp] i es (no t (eqregaddr (rl ,  r2) , 

fetchr(rl,storer(v,  r2,  q)  )  -  f  etchr  ( rl ,  q)  ) 
»  true(); 


end  amstate; 


Figure  2.2:  Specification  of  "amstate" 
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Then  we  have  concrete  algebras  which  describe  an  aggregate  of 
operations  and  sets  of  values  where  the  sets  are  the  source 
for  arguments  and  result  types  of  each  operation.  This  is  a 
system  in  which  there  are  sets  and  operations  that  are 
applied  to  elements  of  the  sets  such  that  the  results  of  the 
operators  stay  in  the  system.  When  we  construct  a 
specification  of  such  a  system,  we  attempt  to  create  a 
specification  that  serves  as  templates  for  the  sets  and 
operators  in  a  concrete  algebra  and  axioms  which  state 
provable  equations  about  the  values  and  operations.  With  such 
a  specification  we  have  something  which  describes  the 
resource  abstractly  and  precisely  without  restricting  it  to  a 
specific  concrete  algebra,  i.e.  there  can  be  many  algebras 
that  are  implementations  of  a  single  specification.  They  are 
considered  as  the  class  of  algebras  uniquely  associated  to 
that  specification. 

1 .  Syntax  versus  Semantics 

We  refer  to  the  syntax  of  description  as  the  "form" 
of  the  description  and  to  semantics  as  the  "meaning"  of  the 
descr i pt ion. 

The  meaning  is  always  determined  by  associating  form 
to  real  objects.  Basically  the  syntactic  part  describes  legal 
expressions  that  can  be  formed  with  the  operators  in  the 
specification.  These  expressions  are  called  formal  terms.  The 
constraint  part  specifies  that  certain  formal  terms  are  to  be 
considered  equivalent.  The  meaning  of  specifications  is 
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established  by  associating  certain  concrete  algebras  to  the 
specification.  There  algebras  represent  the  "real  object”. 
Operational  expressions  in  the  concrete  algebras  are  called 
actual  teras.  Semantics  are  defined  by  a  correspondence 
between  properties  of  formal  terms  and  actual  terms.  A  real 
object  is  a  realization  of  the  abstract  object  defined  by  a 
specification  under  three  conditions  as  they  are  stated  in 
Davis  and  Yurchak  (1984): 

-  Condition  1: 

For  each  operand  type  of  the  specification  there  is  a 
corresponding  set  of  values  in  the  real  object  and  to 
each  operator  in  the  specification  there  is  a 
corresponding  operation  in  the  real  object  that  is 
defined  on  values  that  correspond  to  the  operand  types  of 
the  operator. 

-  Condition  2: 

In  the  correspondence  between  formal  terms  and  actual 
terms,  two  formal  terms  are  provably  equal  if  and  only  if 
their  corresponding  actual  terms  have  the  same  value. 

-  Condition  3: 

To  every  value  of  the  real  object  there  must  correspond 
some  formal  term  whose  corresponding  actual  term  has  that 
value. 

These  conditions  provide  us  with  a  powerful  insight: 
given  a  formal  specification  of  some  resources  there  can  be 
different  implementation  in  the  real  world  (as  they  probably 
are  on  different  machines),  but  as  long  as  the 
implementations  satisfy  the  above  conditions  they  are 
equivalent.  This  is  a  very  important  property  when  the  issue 
of  portability  is  concerned. 

Still  an  formal  specification  despite  its  abstract 
view  of  resources  has  to  deal  with  the  real  world:  for 


exanple  there  is  nothing  like  true  infinite  memory  so  that  a 
defined  operator  like  "nextmemaddr”  (to  obtain  the  memory 
address  of  the  next  instruction  to  be  executed)  will 
eventually  exceed  the  physical  implemented  memory  of  a 
system.  The  "undefined”  has  been  introduced  in  the  formal 
specifications  to  act  like  a  safeguard.  It  indicates  that 
there  is  no  interpretation  in  the  realization  for  this  term. 

B.  PETRI  NETS 

Petri  Nets  are  tools  for  the  study  of  systems  through 
modeling.  The  Petri  Net  theory  has  been  originally  introduced 
by  Carl  Adam  Petri  in  his  doctoral  dissertation  (1962). 
Further  studies  of  A.  U.  Hold  and  Jack  B.  Dennis  helped  to 
develop  this  theory. 

1 .  Terminology  of  Petri  Nets 

From  Peterson  (1981)  a  basic  Petri  Net  is  defined  as 
a  five-tuple  M  =  (P,T,l,0,m)  which  is  composed  out  of  the 
following  parts: 

-  a  set  of  places  P 

-  a  set  of  transitions  T 

-  an  input  function  1 

-  an  output  function  0 

-  a  marking  vector  m 

The  function  1  is  a  mapping  from  a  transition  t^  to  a 
collection  of  input  places  0(tj)  and  the  function  0  is  a 
mapping  of  a  transition  t^  to  a  collection  of  output  places 
Kt^),  the  marking  vector  m  indicates  the  number  of  tokens 
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-  transition  ■  the  process  of  recognizing  true 
preconditions,  the  occurrence  of  an  event,  and  making  the 
postconditions  hold 

-  concurrency  >  two  or  more  events  depending  on  different 
preconditions  can  occur  in  any  order 

-  conflict  s  only  one  of  two  or  more  events  depending  on  at 
least  one  common  precondition  can  occur 

To  give  a  simple  description  of  Petri  Nets  we  can  say  the 
following:  An  event  occurs  (a  transition  is  initiated  or 
enabled)  when  all  of  its  preconditions  hold.  The  effect  of 
the  occurrence  is  that  the  tokens  of  the  preconditions  are 
"used”  for  the  event  and  then  distributed  to  the 
postconditions. 

The  following  constructors  can  be  recognized  in  Petri  Nets: 

-  siaple  transitions  ■  there  is  one  precondition  and 
whenever  this  condition  holds  the  event  occurs  so  that 
the  token  from  the  precondition  is  removed  and  after  the 


occurrence  of 

the  event 

the  token 

i  s 

moved 

to  the 

postcondition 
2.4) . 

so  that  this 

condition 

now 

holds 

( Fi  gure 

**  conjunctive 

transitions 

*  there 

are 

two 

or  more 

preconditions 

that  a  1 1  have 

to  hold 

in 

order 

for  the 

event  to  occur.  All  tokens  of  the  preconditions  are  used 
and  after  the  occurrence  of  the  event  only  one  token  is 
moved  to  the  postcondition  to  indicate  that  it  now  holds 
(Figure  2.5). 

-  disjunctive  transitions  *  one  precondition  is  connected 
to  two  or  more  events  and  when  this  precondition  holds 
one  of  the  events  will  occur  and  will  move  the  token  from 
the  precondition  to  the  postcondition  of  that  event  that 
occurred.  The  selection  of  the  event  to  occur  is 
non>deterministic  (Figure  2.6). 

-  distributive  transitions  *  there  is  one  precondition  and 
when  this  holds  the  connected  event  will  occur.  It  will 
remove  the  token  from  the  precondition  and  it  to  all 
postconditions  so  that  every  postcondition  of  this  event 
will  have  a  token  (Figure  2.7). 

~  coaplex  transitions  ■  combinations  of  the  above  simple 
constructs  of  Petri  Nets. 


before  euent 


after  euent 


Figure  2.6:  Disjunctive  Transition 


2.  Properties  of  Petri  Nets 

Petri  Nets  by  their  nature  are  well  suited  to  model 
asynchr onuous  processes,  i.e.  where  the  progress  of  a  process 
is  controlled  by  conditions  and  events  and  not  by  some  kind 
of  fixed  clock.  This  means  that  in  some  part  of  the  net  there 
can  be  waiting  for  a  condition  to  start  an  event,  even  the 
case  that  a  process  cannot  continue  because  of  a  missing 
condition.  Suppose  an  event  is  modeled  as  a  conjunctive 
transition  as  indicated  in  Figure  2.5.  If  the  precondition 
C, , , ,  is  never  true  the  process  will  stop  at  this  point.  The 
"flow”  of  the  progress  can  always  be  observed  by  the  state  of 
the  condition  places  in  the  system.  The  occurrence  of  events 
is  recognizable  by  the  changing  of  the  preconditions  and 


postconditions. 


The  discussion  of  disjunctive  events  has  shown  an 
important  property  of  Petri  Nets:  their  non-deterministic 
nature,  i.e.  we  have  under  normal  circumstances  to  force  a 
distributive  construct  in  one  or  the  other  direction.  This  is 
a  major  obstacle  when  we  have  to  model  some  kind  of  decision 
making  in  a  Petri  Net.  One  way  to  get  around  this  problem  is 
the  construct  (introduced  by  Peterson  (1981))  of  an  "external 
agent"  which  provides  appropriate  TRUE  or  FALSE  places  at 
decision  points  in  the  net.  Here  by  the  intervention  of  the 
"external  agent"  the  process  proceeds  in  the  direction  of  the 
TRUE  or  FALSE  place.  In  general,  one  can  think  of  "external 
agents"  as  CASE-constructs  in  high-level  programming 
languages  such  that,  dependent  on  the  value  of  an  argument, 
one  and  only  one  action  is  taken  by  setting  the  according 
place  in  the  net.  Ue  will  discuss  this  topic  further  in 
Chapter  IV. 

When  we  look  at  the  conjunctive  and  distributive 
constructs  we  observe  that  by  combining  them  we  can  build  a 
distributive  construct  which  "fans"  out  into  several  holding 
places  and  then  combines  again  with  a  conjunctive  construct. 
In  this  way,  we  have  able  to  introduce  parallelism  into  Petri 
Nets.  Figure  2.8  shows  the  graph  of  a  process  that  fans  out 
into  five  processes  which  then  merge  again  into  one  process. 
This  capability  of  Petri  Nets  is  very  powerful  and  convenient 
in  specifying  computer  resources. 


Figure  2.8:  Parallelism  with  Petri  Nets 


3 .  Modeling  with  Petri  Nets 

Modeling  with  Petri  Nets  has  been  widely  used  in  very 
different  areas:  computer  software,  computer  hardware, 
chemical  reactions,  queuing  theory,  political  systems,  etc.. 
Two  examples  as  they  are  presented  by  Peterson  (1981)  are 
given  to  illustrate  this  modeling  work:  a  portion  of  a  Petri 
Net  showing  a  control  unit  of  a  computer  with  multiple 
registers  and  functional  units  as  an  example  for  modeling 
computer  hardware  (Figure  2.9)  and  a  Petri  Net  dealing  with 
the  mutual  exclusion  problem  as  example  for  modeling  computer 
software  (Figure  2.10). 

In  our  approach  we  want  to  exploit  the  ease  and  the 
properties  of  Petri  Nets  for  modeling  the  combination  of 


computer  hardware  and  software  as  they  operate  in  time. 


section 
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III.  THE  PROBLEM  OF  TIMING  SPECIFICATION 


A.  GENERAL  PROBLEMS 

Why  are  we  so  concerned  about  the  timing  of  a  system? 
Time  is  an  important  resource  in  computer  systems  that  must 
be  managed  carefully.  There  is  almost  always  the  possibility 
that  if  we  invest  more  of  other  resources  we  are  able  to 
reduce  the  amount  of  time  a  piece  of  work  will  need. 
Everybody  remembers  a  mathematical  problem  like  this:  if  it 
takes  one  unit  to  accomplish  a  task  in  x  hours  how  many  hours 
will  it  take  y  units  to  do  the  same  task?  In  this  very  simple 
problem  the  increase  of  other  resources  (e.g.  units)  will 
reduce  the  needed  time  for  the  task  linearly. In  computer 
systems  we  could  save  time  by  implementing  more  CPUs,  disk 
drives,  arithmetic  units,  etc..  But  since  more  hardware  costs 
more  money  and  the  control  of  additional  resources  uses  time 
by  itself  we  have  to  be  very  careful  in  determining  the 
resources  we  need  and  how  we  use  them.  The  following  example 
shows  the  danger  of  mismanaging  computer  resources:  a 
computer  task  that  requires  some  resources  (e.g.  disks)  would 
waste  them  it  it  holds  more  than  it  needed  at  times  when  it 
actually  does  not  need  them  and  so  prohibits  other  tasks  from 
using  them. 

The  formal  specification  as  described  in  the 
specification  of  the  Abstract  Processor  is  only  concerned 


with  static  computer  resources,  i.e  the  timing  properties  are 
implied  by  the  functional  relations  between  components  of  the 
system.  The  static  specification  is  purely  functional.  For 
example,  operands  must  be  evaluated  before  a  function  is 
applied  but  there  is  no  way  of  indicating  the  order  of 
evaluation.  The  dynamic  computer  resources  are  those  that 
express  an  ordering  of  resources  in  time,  mutual  exclusion 
and  concurrency.  Instead  of  assuming  some  ordering  in  the  use 
of  computer  resources  we  want  to  be  able  to  explicitly  state 
and  define  the  timing  of  a  system. 

The  goal  is  to  specify  the  required  timing  properties 
precisely  to  a  desired  degree  which  for  example  is  sufficient 
to  evaluate  the  system  for  time  and  cost  efficiency.  The 
relation  between  time  and  cost  depends  on  the  nature  of  the 
system:  there  is  much  more  emphasis  on  time  in  system  that 
are  very  time  critical  (e.g.  real-time  systems)  and  not  so 
much  on  systems  that  are  purely  problem  solvers. 

The  basis  of  this  work  is  to  show  whether  such  a 
methodology  for  specifying  timing  properties  can  be  based  on 
the  theory  of  Petri  Nets  and  how  well  the  special  cases  of 
timing  in  computer  system  resources  can  be  expressed  in  terms 
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of  Petri  Nets. 
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B.  SPECIFIC  PROBLEMS  OF  INTEREST 


1 .  Order  of  Evaluations  of  Functions 


Given  e  function  f ( xt » Xa , . . . , Xn )  we  only  require  that 


Xt  to  Xn  are  evaluated  before  f  can  be  applied.’  There  is  no 


statement  that  the  evaluation  of  Xi  has  to  be  started  first 


or  what  evaluation  has  to  be  completed  first. 


trallel  Processing  of  Parts  of  Functions 


Considering  again  our  function  f ( Xt , x* , . . . , x„ )  we 


want  to  state  explicitly  which  evaluations  have  to  performed 


in  parallel  and  which  in  sequence.  Why  do  we  want  to  do  so? 


Following  our  purpose,  in  the  specification  we  want  to 


describe  timing  in  a  way  which  is  as  exact  and  detailed  as  a 


timing  diagram  used  to  construct  hardware. 


3.  Mutual  Exclusion 


A  major  problem  that  arises  with  parallelism  is 


mutual  exclusion,  i.e.  a  computer  resource  can  only  be  used 


by  one  process  at  a  time  and  the  use  of  the  resource  has  to 


have  a  certain  entry  and  exit  point  to  preserve  the  integrity 


of  the  resource. 


Consider  a  simple  computer  with  a  memory  unit  which 


retrieves  and  stores  data  on  request  via  a  specified 


Interface  (Memory  Buffer  Register  and  Memory  Address 


Register).  This  is  parallelism  even  in  simple  computers  since 


the  memory  is  independent  from  the  CPU.  So  we  have  to  make 


’Even  if  X  is  a  constant  it  has  still  to  be  evaluated, 
i.e.  its  value  has  to  be  retrieved 
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sure  that  only  one  request  is  handled  by  the  nenory  unit  at  a 
time  and  that  the  next  one  is  handled  when  the  first  one  is 
finished.  We  want  to  be  able  to  explicitly  state  those 
properties  in  the  specification  of  timing  systems. 

4.  Data  Flow 

During  the  course  of  a  process  in  time  certain  data 
has  to  be  available  in  order  for  the  process  to  proceed.  Some 
data  is  changed,  other  data  is  not  needed  anymore.  Here  we 
have  the  problem  of  how  to  model  data  flow  by  means  of  Petri 


Nets. 


To  make  this  point  more  clear  let  us  consider  the 


execution  of  following  instruction:  SUB  R1,R2  (subtract  the 
contents  of  register  1  from  the  contents  of  register  2  and 
store  the  result  in  register  2).  During  the  execution  we  have 
to  retrieve  the  identities  of  the  registers  from  the 
instruction  <i.e.  the  instruction  has  to  be  decoded)  then 
their  contents  both  have  to  be  available  before  we  can 
perform  the  subtraction.  At  this  point  of  the  execution  we  do 
not  need  the  identity  of  the  first  register  anymore,  but  the 
one  for  the  second  since  it  is  not  only  a  source  for  the 
operation  but  also  the  destination.  Thus,  we  have  to  have 
some  mechanism  in  our  methodology  to  state  data  which  is 
available  during  the  course  of  the  execution. 


SPECIFICATIONS 


In  previous  work  computer  resources  have  been  formally 
specified  using  basically  the  algebraic  specification 
approach.  In  essence,  this  is  a  type  of  functional 
specification.  The  question  we  address  here  is  can  functional 
specification  be  extended,  using  Petri  Net  theory,  to  provide 
for  the  specification  of  timing  properties. 

A.  GENERAL  APPROACH 

Given  a  general  function  f (X| , Xa , . . . , x„  )  what  are  the 
stages  of  evaluation  for  this  function? 

-  the  evaluation  of  f ( x, , Xa , « . . , Xn >  must  have  been 
requested  from  somewhere  and  by  this  the  evaluation  gets 
into  a  requested  stage 

for  al  1  X,  ^  evaluation  is  requested 

which  starts  for  all  x,  a  new  process  with  the  same 
stages  as  described  here 

-  once  all  x,  are  evaluated  and  their  results  are  available 
to  our  function  f  it  can  be  evaluated  in  a  processing 
stage 

-  when  the  evaluation  is  completed  and  the  result  is 
available  the  process  is  completed 

Note  the  similarity  to  the  "natural"  way  a  human  being 
would  calculate  this  function:  if  we  were  to  calculate 
sum ( sin( X*  ) , sqrt (y ) )  we  had  to  calculate  the  square  root  of  y 
and  we  had  to  square  x  and  take  the  sine  of  it  and  then  we 
would  apply  the  sum-function  to  the  intermediate  results. 


However,  this  example  exhibits  a  problem  for  our  very  general 
approach:  how  do  we  know  what  the  values  of  x  and  y  are  and 
how  do  we  know  that  e.g.  "sqrt"  means  "take  the  square  root". 
Therefore  there  must  be  some  decoding  and  retrieval  steps  in 
between  which  determine  what  the  parts  of  the  function 
expression  mean.  This  is  exactly  the  case  when  we  consider 
computer  instructions:  e.g.  given  an  instruction  like  "ADD  R1 
M2  R3"  which  means  "add  the  contents  of  register  1  to  the 
contents  of  memory  address  2  and  store  the  result  in 
register  3".  Here  the  following  steps  have  to  be  performed: 

-  The  instruction  has  to  be  decoded  (we  assume  that  at  this 
stage  the  instruction  is  already  retrieved):  i.e.  the 
components  of  the  instruction  (operator  and  operands) 
must  be  made  available  to  the  further  evaluation. 

-  Up  to  this  stage  only  the  names  (i.e.  the  symbolic 
addresses)  of  the  operands  are  available  and  so  the  next 
step  is  to  retrieve  the  values  of  the  operands. 

-  Now  that  the  operator  and  the  values  of  the  operands  are 
available  the  operation  designated  by  the  operator  can  be 
performed. 

-  When  the  result  is  available  it  can  be  stored  into  the 
location  which  expressed  by  the  third  operand. 

Figure  4.1  shows  the  corresponding  graph  of  a  Petri  Net 

describing  the  above  steps.  In  this  example  we  see  an 

approach  to  describe  the  execution  of  an  instruction  in  a 

sequential  manner.  Suppose  we  had  a  machine  that  could 

perform  retrieval  of  values  and  operation  in  parallels,  how 

could  we  describe  that  certain  steps  could  be  performed  in 

parallel  and  how  could  we  mark  points  in  time  where  the 

process  can  only  proceed  if  some  results  are  available? 
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Figure  4.1:  Simple  Instruction  Execution  Net 


This  is  the  point  where  we  can  use  the  properties  of 
Petri  Nets:  if  we  model  requests  and  availabilities  as  places 
of  Petri  Nets  and  the  actions  on  requests  and  availabilities 
as  transitions  and  connect  them  accordingly  we  are  in  a 
position  to  model  the  evaluation  of  a  function  or  the 
execution  of  an  instruction. 

Up  to  this  point  there  is  nothing  new  in  our  methodology 
since  modeling  with  Petri  Nets  is  common  practice  and  has 
been  done  for  a  long  time.  The  question  to  be  ask  now  is  does 
a  methodology  based  on  Petri  Nets  provide  the  means  to 
specify  the  specific  problems  of  computer  systems  and  their 
components  in  a  way  that  is  consistent  with  the  formal 
specification  of  the  static  properties  we  have  seen  in  the 
specification  of  the  Abstract  Processor. 

In  addition  we  not  only  want  to  look  at  the  timing  of 
systems  in  an  isolated  fashion,  but  also  we  want  to  combine 
the  specification  of  static  properties,  as  Introduced  in  the 
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specification  of  the  Abstract  Processor,  with  the 
specification  of  dynamic  properties  of  such  a  system.  With 
this  combination  we  can  specify  systems  completely. 

B.  NOTION  OF  SUBNETS 

Now  that  we  have  Petri  Nets  as  a  tool  we  can  model  simple 
timing  systems  using  our  methodology.  However,  we  would  like 
to  simplify  and  eliminate  redundancy:  if  we  use  the  same 
structure  in  a  net  several  times,  it  would  be  better  to  have 
this  structure  defined  once  and  reference  this  definition 
wherever  we  need  it  in  our  system  (Figure  4.2).  As  an 
example,  suppose  we  realize  that  a  structure  to  make  the 
contents  of  a  certain  memory  address  available  to  the  process 
appears  several  times  in  our  system.  By  defining  this 
retrieval-function  as  a  subnet  vie  are  in  a  position  to  use  it 
everywhere  in  the  system  simply  by  setting  its  ENTRY-place 
(in  our  example  with  a  request  for  value  of  a  specified 
register)  and  we  obtain  the  result  (the  value  of  the 
specified  register)  at  its  EXIT-place.  This  works  even  for 
the  case  that  the  subnet  specifies  a  computer  resource  that 
has  to  be  accessed  observing  mutual  exclusion. 

The  major  question  that  has  to  be  asked  here  is  how  can 
we  model  such  a  subnet  that  has  the  ability  to  "sense”  where 
it  has  been  invoked  and  so  can  return  its  results  to  that 
location  in  the  system.  Computer  language  constructs  like 
procedures  or  functions  use  a  return  address  which  is  saved 
with  the  call  of  the  procedure/function  to  determine  the 
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location  in  the  program  which  has  to  be  executed  after  the 


pr ocedur e/ f unct i on  is  finished.  Our  model  of  using  Petri  Nets 
is  different  in  this  aspect:  despite  the  fact  that  it  shows 
the  dynamic  behavior  of  a  system,  its  structure  is  static  and 


does  not  change  in  time  and  so  all  connections  between  nets 
and  subnets  are  established.  Since  we  have  to  know  all  these 


Figure  4.2:  Symbology  of  Subnets 


connections  we  are  able  to  provide  for  each  connection  an 
entry-place  which  is  connected  to  the  net  internally  by 
disjunctive  events  such  that  only  one  can  be  "fired"  at  a 
time.  The  "firing"  of  those  events  lets  a  path-place  hold 
that  indicates  the  entry-place  which  triggered  the  event. 
This  path-place  decides  what  exit-place  is  set  when  the 
internal  net  provides  the  result. 

This  definition  of  a  subnet  is  a  very  powerful  shortcut 
for  keeping  descriptions  of  systems  limited.  It  resembles  a 
function  construct  in  a  high-level  programming  language:  it 
is  been  "called"  by  setting  its  request -place,  does  itc 
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posed  w 
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Figure  4.3:  Generalized  Subnet  without  Mutual  Exclusion 


Figure  4.4:  Generalized  Subnet  with  Mutual  Exclusion 


We  have  to  show  that  our  methodology  is  capable  of 


defining  subnets  and  introducing  them  into  other  nets. 


C.  COMBINING  NETS 

With  the  introduction  of  subnets  we  are  in  need  of  rules 
and  guidelines  on  how  we  can  combine  a  collection  of  small 
nets  and  subnets  into  a  timing  system. 

I .  Coupling  of  Nets 

In  the  preceding  paragraph  we  have  assumed  that  nets 
are  connected  by  entry  and  exit  places,  but  generally,  we 
have  two  possibilities  to  connect  nets: 

-  Coupling  by  places:  to  connect  two  nets  the  first  net 
outputs  to  a  EXIT-pIace  that  is  read  by  the  second  net  as 
an  ENTRY-place.  In  the  special  case  that  we  use  subnets 
in  our  specification  we  request  the  subnet  by  place  (the 
ENTRY-place  of  the  subnet)  and  obtain  the  result  by  a 
place  (the  EXIT-place  of  the  subnet). 

-  Coupling  by  events:  events  are  shared  between  nets  and 
when  the  ENTRY-event  "fires"  the  requested  net  is  invoked 
and  signals  the  availability  of  the  result  by  "firing" 
Its  EXIT-event. 

We  have  chosen  the  coupling  of  nets  by  places  because 
of  the  following  reasons: 

-  The  request  for  a  subnet  submitted  by  a  place  allows  the 
requested  subnet  more  "liberty"  to  react  on  the  request 
only  when  it  is  ready  to  do  so  since  the  pending  request 
as  a  "loaded"  place  remains  until  it  is  used  by  the  net, 
where  as  in  event-coupling  the  saving  requests  had  to  be 
done  in  a  more  complicated  way. 

-  The  coupling  of  nets  by  places  resembles  the  way  events 
like  interrupts  are  processed  in  real  machines,  here  the 
interrupt  does  not  interrupt  the  execution  of 
instructions  at  any  time,  but  a  status  "interrupt"  is  set 
and  this  status  is  checked  between  the  execution  of 
instructions  and  acted  upon. 


2.  Extensions  of  Nets 

To  make  our  methodology  consistent  we  need  to  state 
what  other  nets  we  are  going  to  use  in  this  net.  There  is  a 
close  similarity  to  INCLUDE,  USE  or  WITH  constructs  of  high- 
level  programming  languages  or  the  EXTEND  construct  of  the 
formal  specification.  In  the  specification  of  timing  the 
mentioning  of  a  net  to  be  the  extension  of  another  means  that 
the  parent  net  is  going  to  use  the  extended  net  as  a  subnet 
in  the  specification. 

3.  Net  Selection 

Due  to  the  non-deterministic  nature  of  Petri  Nets  we 
do  not  have  a  traditional  net  construct  which  can  make 
decisions  on  truth  or  falseness  and  directs  the  path  in  the 
net  accordingly.  A  proposed  solution  for  this  problem  by 
Peterson  (1981)  is  to  use  "external  agents"  as  they  were 
presented  in  Chapter  2.  This  construct  is  able  to  examine  a 
status  or  data  on  a  given  condition  and  make  the  decision 
whether  the  condition  is  fulfilled.  With  the  outcome  of  the 
decision  a  path  to  a  place  representing  true  or  the  place 
representing  false  is  set.  By  extending  this  idea  we  able  to 
think  of  "external  agents"  as  a  CASE-statement  where  one  and 
only  way  through  the  net  is  chosen  according  to  a  condition 
(see  Figure  4.5). 

D.  TYPING  OF  NET  ELEMENTS 

In  the  traditional  Petri  Net  theory  we  have  tokens  to 


Indicate  the  flow  through  the  net  and  to  mark  holding  places. 
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So  the  "firing"  of  an  event  consists  in  collecting  a  token 
from  each  of  the  connected  input  places,  performing  the 
designated  action  and  distributing  a  token  to  each  connected 
output  place.  This  is  not  enough  when  we  want  to  describe  the 
flow  of  data  in  time.  Also  we  want  to  be  able  to  state 
specifically  what  kinds  of  data,  what  types  of  data  are  being 
requested,  available  or  transferred  at  a  certain  point  in  the 
timing  of  a  system. 


goal  better 
methodo 1 ogy . 


to  develop  a  practical  and  understandable 


1 .  Typed  Places 

When  we  Introduce  a  concept  of  typed  places  we  still 
have  the  original  meaning  of  the  tokens  to  indicate  the 
holding  of  a  place.  The  presence  of  data  of  a  certain  type 
must  be  accomplished  by  means  that  have  to  obey  the  type  of 
the  place.  The  events  still  react  on  the  presence  of  tokens 
in  the  places. 

2.  Typed  Tokens 

This  alternative  considers  a  token  as  a  construct 
that  carries  an  actual  piece  of  data  according  to  the  type  of 
the  token.  We  can  imagine  tokens  as  a  message  residing  in  the 
places.  The  events  now  can  be  modeled  by  picking  up  a  message 
from  each  connected  input  placed,  performing  their  designated 
actions,  and  distributing  a  message  to  every  connected  output 
place . 

So  now  we  can  look  at  places  in  a  net  as  constructs 
that  can  receive  token-messages  from  events,  keep  them  and 
send  them  to  events.  The  actions  performed  by  events  consist 
of  picking  up  message- tokens  from  places,  changing  and 
creating  message- tokens  and  sending  them  to  places. 

3.  Typed  Tokens  in  Typed  Places 

Both  concepts  above  exhibit  some  disadvantages: 

-  Pure  place  typing  needs  some  external  mechanism  to 
establish  the  presence  of  data. 


-  Pure  token  typing  allows  a  message- token  to  be  sent  to 
every  place  in  the  net  since  there  no  protection  from 
receiving  message- tokens  of  the  wrong  type. 

This  leads  to  the  idea  of  combining  both  typing 
schemes.  With  this  concept  we  restrict  places  in  the  net  to 
accept  only  tokens  of  a  certain  type  and  the  tokens  are 
actually  typed  messages.  One  small  problem  does  arise  here: 
what  if  we  want  in  some  situations  the  token  to  have  its 
original  meaning  only  to  indicate  its  presence  without  any 
data?  This  reminds  of  a  message  without  contents.  As  a 
solution  we  introduce  following  typing  convention: 

-  A  place  declared  to  be  of  a  certain  type  or  collection  of 
types  can  only  accommodate  tokens  that  are  messages  of 
this  type  or  collection  of  types. 

-  A  place  declared  to  be  of  no  type  can  only  accommodate 
tokens  which  are  "empty”  messages. 

-  An  event  will  collect  typed  token-messages  from  the 
connected  typed  input-places,  perform  its  designated 
action  and  output  typed  token-messages  to  the  connected 
typed  output-places. 

With  this  typing  scheme  we  are  now  in  a  situation  to 
specify  data  flow  in  time  by  means  of  typed  tokens  and 
places.  Although  we  have  based  our  work  on  Petri  Nets  we  see 
that  our  concept  has  become  more  general  and  now  reminds  of  a 
general  message  passing  system. 


E.  SYNTAX 

Since  our  approach  includes  the  existing  specification 
methodology  of  the  static  computer  resources,  we  have  to 
carefully  develop  a  new  syntax  which  expresses  both  the 
static  and  dynamic  properties  of  the  systems  to  be  specified. 
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The  following  syntax  has  been  introduced  with  the 
specification  of  the  Abstract  Processor  by  Davis  and  Yurchak 
(1985)  : 

Resource  <naee>  is 
Operand  Types 

<operand  types> 

Operators 

<operators> 

Properties 

<properties> 

The  following  requirements  have  to  be  fulfilled  by  the 
syntax  we  want  to  develop: 

-  It  has  to  have  the  ability  to  express  both  the  static  and 
dynamic  properties  of  system  properties  where  the  static 
part  should  be  left  in  the  form  as  introduced  by  Davis 
and  Yurchak  (1984). 

**  The  form  of  the  syntax  should  be  as  simple  and  easy  to 
understand  as  possible. 

-  The  chosen  names  of  the  constructs  of  the  syntax  should 
be  self-explanatory  and  suggest  the  intended  meaning  to 
the  user. 

-  It  has  to  provide  a  precise  and  unambiguous  way  to 
specify  the  system. 

Another  point  to  consider  is  that  we  want  to  follow 
certain  accepted  design  principles,  especially  that  of 
Information  Hiding  as  it  is  done  e.g.  in  the  ADA  package 
construct  where  there  is  a  Package  Interface  (to  provide  the 
user  of  the  package  with  all  the  information  necessary  to  use 
the  package  and  nothing  else)  and  a  Package  Body  (the 
implementation  of  the  package). 

Before  we  finalize  the  syntax  for  the  dynamic 
specification  of  a  system  we  need  to  say  something  about  how 
the  dynamic  properties  of  static  objects  are  described  in 


terns  of  places  and  transitions.  Places  reflect  the 
conditions  on  the  execution  of  the  static  functions,  whereas 
transitions  are  used  to  describe  changes  in  these  conditions 
during  the  execution  of  the  static  functions.  Sone  of  these 
places  and  transitions  are  generic,  i.e.  they  apply  to  any 
function.  For  example,  a  function  is  always  requested  by  a 
place  and  becomes  activated  by  an  aotivate-transi tion.  This 
does  not  prevent  us  from  defining  additional  places  and 
transitions  when  they  are  needed  for  a  specification.  Ue  are 
going  to  use  an  uniform  notation  to  indicate  the  connection 
between  the  statement  of  the  dynamic  properties  and  the 
static  properties.  Given  an  operator  storem  :  val,  aemaddr, 
state  ->  state  we  will  use  internal  places  names  that  are 
preceded  by  storea_  (e.g.  storem_acti vated)  and  transition 
names  that  are  followed  by  _8torem  (e.g.  acti vate_storem) .  Ue 
also  reserve  standard  notations  for  entry  and  exit  places  of 
subnets:  entry  places  are  always  preceded  by  req_  (e.g. 

req_storem  for  "request  a  store  in  memory")  and  exit  places 
are  always  preceded  by  avail_  (e.g.  avail_storem  for  "result 
of  store  in  memory  is  available).  Ue  reverse  the  order  of 
attaching  the  name  of  the  function  because  we  want  to 
emphasize  that  a  subnet  represents  a  transition  that  is 
specified  in  detail. 

1 .  P 1  aces 

There  are  three  types  of  places  we  want  to 


distinguish  in  our  syntax: 


-  internal  places,  which  names  and  definitions  are  only 
known  and  accessible  within  the  net  they  are  defined  in; 
the  purpose  is  to  build  the  internal  structure  of  the  net 

-  entry  places,  which  names  and  definition  are  also  known 
and  accessible  to  those  nets  which  are  declared  to  be 
extensions  of  this  net;  they  provide  an  interface  to 
invoke  this  net 

-  exit  places,  which  names  and  definitions  are  known  and 
accessible  to  those  nets  which  are  declared  to  be 
extensions  of  this  net;  they  provide  an  interface  to 
obtain  the  results  from  the  invocation  of  this  net 

We  have  chosen  the  following  syntax  to  describe 
places  in  our  specification: 

place_naae(netlabel ) Cmessage^type]. 

A  place_name  is  the  distinct  name  of  a  place  in  the  described 
net.  In  the  case  that  a  place  is  either  an  entry  or  exit 
place  the  rule  applies  that  their  names  are  known  to  those 
nets  which  are  declared  to  be  extensions  of  this  net.  If  a 
net  has  multiple  entry  or  exit  places  the  parameter  netlabel 
can  be  attached  in  parentheses  to  describe  this  fact  where 
netlabel  indicates  a  location  in  the  system.  As  we  have  said 
a  place  is  able  to  accommodate  a  certain  kind  of  message  so 
the  type  of  the  message  the  place  can  hold  in  brackets  is 
part  of  the  place  description.  The  following  description  of 
places  are  legal  (compare  with  the  static  specification  for 
"fetchr"  and  "storem"  in  Chapter  II): 

-  storem_activatedCval . memaddr. state] ;  a  place  of  the  name 
"storem.acti vated”  which  can  hold  messages  that  consist 
of  data  of  type  val,  memaddr  and  state 

-  f etohr_avai I C ] ;  a  place  of  the  "f etchm_avai 1 ”  which  can 
only  hold  empty  messages 


~  r«q_j>usha  tk(  net  label )  Cval .  stkaddr.  states  {  places  of  the 
nane  ”req_pushstk''  which  are  distinguished  by  the 
parameter  "net label",  all  of  then  able  to  hold  messages 
which  contain  data  of  types  val,  stkaddr  and  state. 

2.  Transitions 

Our  methodology  defines  transitions  as  the  process  of 
collecting  a  message  from  each  connected  input  place  and 
sending  messages  to  every  connected  output  place.  So  we  want 
to  state  what  kind  of  messages  are  received  and  transmitted. 
The  following  syntax  is  used  to  describe  transitions: 
transi tionjnaae: input_nes8ages  >>  output_ne8sages. 

The  transition_naae  is  a  distinct  name  for  the  transition  in 
the  net  and  is  not  known  outside  the  net.  Input  and  output 
messages  are  of  the  above  form  where  multiple  messages  are 
separated  by  commas.  The  following  examples  are  legal 
description  of  transitions: 

-  psrfora_storsa:  Cval .memaddr. stats]  *>  C state!} 

the  transition  of  the  name  "perf orm_storem"  takes  a 
message  which  contains  data  of  type  val,  memaddr  and 
state  as  input  and  outputs  a  message  containing  data  of 
type  state 

-  f inish.fetchr:  (val],[]  ->  Cvall.C]} 

the  transition  of  the  name  "f ini sh_f etchr "  takes  two 
messages  as  input  where  one  consists  of  data  of  type  val 
and  the  other  is  an  empty  message  and  outputs  again  two 
messages  of  same  type 

Note  that  the  description  of  transitions  only 
declares  them  in  terms  of  their  capabilities  to  accept  and  to 
transmit  certain  kinds  of  messages  and  does  not  show  any 
internal  action  of  the  transition.  The  reason  for  this  is  to 
present  the  transitions  as  building  blocks  of  the  net  in  form 
of  a  mapping  function  which  is  general  enough  to  provide 


information  about  its  interface  and  nothing  more.  The 
internal  actions  are  described  as  the  properties  of  the  net. 
This  does  not  necessarily  means  that  a  transition  is 
instantaneous,  rather  the  complexity  of  the  internal  actions 
determine  the  duration  of  the  transition.  But  every  complex 
transition  can  be  modeled  as  a  net  with  entry  and  exit  places 
such  that  the  internal  transitions  become  instantaneous. 

3.  Properties 

Now  that  we  have  described  the  building  blocks  of  a 
net  we  need  to  connect  them  in  order  to  describe  the  intended 


timing  of  a  system.  The  following  form  is  chosen  for  the 
syntax  of  the  properties  of  the  net: 
t rans i t i on_name ( p I ace_names C mes8age_da ta >  « > 

placejnamesCmessage.datal ;  This  form  shows  how  places  and 
transitions  are  connected  and  how  the  transfer  of  message 
elements  occurs  between  them.  Here  are  some  examples  of  legal 
property  descriptions: 

-  perform_fetohm<fetohmjaotivated[m.q)>  ■> 

fetohm_oompleted[ vl I  the  transition  ”per f orm_f  etchm” 
occurs  when  there  is  a  message  in  the  place 

''fetchm_activated''.  The  message  is  taken  from  the  place 
in  such  a  way  that  all  message  elements  (memaddr  m  and 
state  q)  are  available  to  the  transition.  Then  the  action 
of  getting  the  memory  contents  is  performed  and  the 
resulting  value  v  is  transmitted  as  a  message  to  the 
place  "f etchm_compl eted” 

-  porform.storer(storer_activatedCv. r.q] >  ■> 

8torer_completodtql 1 1  the  transition  "per f orm_storer" 

occurs  when  there  is  a  message  in  the  place 
”storer_act ivated"  in  such  a  way  that  the  message  is 
taken  from  the  place  in  such  a  way  that  its  message 
elements  (value  v,  regaddr  r  and  state  q>  are  available 
to  the  transition.  The  action  of  storing  the  value  v  in 


register  r  Is  perforned  and  the  new  state  ql  is 
transmitted  as  a  message  to  the  place  ”storer_comp I eted” 

Functionally,  the  internal  actions  performed  by 
transitions  fol low  the  rules  stated  as  static  properties  for 
the  functions  involved. 

4.  Initial ization 

In  some  kinds  of  nets  we  have  an  internal  circuit  of 

places  in  order  to  act  as  a  synchronization  mechanism  (as 

illustrated  in  Figure  4.4  to  provide  mutual  exclusion).  They 

have  to  be  initiated  somehow  i.e.  a  message  has  to  be  placed 

in  at  least  one  of  these  places  since  they  are  not  provided 

with  messages  from  outside  the  net.  Ue  going  to  describe  this 

initialization  by  using  the  symbol  "=>"  used  to  indicate  the 

placement  of  a  message  into  a  place.  The  following  is  an 

example  of  an  initialization: 

«>  f etohm_javmi  1  C  ]  }  the  place  "f etchm_avai  I ”  is  loaded 
with  an  empty  message 

The  initialization  of  a  place  is  a  one-time  action  at 
the  beginning  of  system  start  and  provides  the  necessary 
conditions  to  get  a  process  going,  it  can  be  viewed  as 
establishing  the  initial  state  of  a  computer  system  when  it 


is  turned  on. 
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HE  ABSTRACT  PROCESSOR  TIMING  SPECIFICATION 


In  this  chapter  we  want  to  present  sone  examples  on  how 
specific  problems  of  timing  in  computer  system  can  be  modeled 
using  the  methodology  in  a  top-down  fashion.  The  examples 
resemble  a  variety  of  computer  system  timing  problems  to  test 
the  use  of  Petri  Nets  in  specifying  the  timing  properties.  In 
Appendix  B  a  complete  specification  of  the  static  and  dynamic 
properties  of  a  reduced  Abstract  Processor  is  presented.  Ue 
have  chosen  to  use  the  Abstract  Processor  as  the  object  to  be 
specified  in  timing  considerations  because  of  the  following 
reasons : 

-  to  emphasis  this  work  as  the  logical  step  following  the 
work  of  specifying  static  properties  of  systems, 

-  by  specifying  a  non-existent,  abstracted  processor  we 

intentionally  leave  the  issue  of  the  actual 

implementation  untouched  since  we  stated  that  by  whatever 
means  the  specification  is  implemented  the  processor  will 
have  the  specified  properties, 

-  to  emphasize  our  intention  of  specifying  what  the  user  of 

a  processor  wants  to  achieve  and  not  how  it  is 

implemented  as  compared  to  a  traditional  processor  design 
approach  that  is  dominated  by  engineering  and 

implementation  issues. 

Also  we  want  to  show  how  well  our  methodology  can  deal 
with  the  special  aspects  of  timing  in  computer  systems.  The 
special  aspects  we  are  concerned  with  are  mutual  exclusion, 
interrupt  processing  and  concurrency.  Despite  the  fact  that 
the  Abstract  Processor  is  in  its  static  part  specified  as  a 
simple  single  processor  during  this  work  we  have  realized 


that  even  there,  a  lot  of  potential  concurrency  can  be 
detected. 

Whenever  we  refer  to  actual  lapl eoentation  we  do  this 
with  the  intention  to  give  one  example  of  how  the 
specification  could  be  realized.  Once  again  we  emphasize  that 
the  methodology  stated  in  this  work  is  only  concerned  with 
what  is  available  in  a  system  and  not  with  the  how  it  is 
implemented.  We  want  to  remind  the  reader  that  the 
methodology  developed  here  is  intended  to  be  general.  That 
is,  it  can  be  equally  applied  to  the  specification  of 
computer  resources  that  may  be  implemented  in  hardware, 
software  or  firmware.  With  this  in  mind  we  have  look  at  the 
timing  specification  not  as  a  blueprint  by  which  a  system  can 
be  build  directly  but  rather  as  formally  stated  requirements 
a  system  has  to  fullfil  no  matter  what  approach  is  chosen  for 
the  implementation  . 

A.  ATOMIC  NETS 

One  feature  of  the  methodology  is  it  forces  the  specifier 
to  focus  on  the  essential  nature  of  the  system  components. 
When  we  consider  these  essential  components  as  actions  in  a 
system  that  are  not  further  divisible  we  can  speak  of  atomic 
actions  which  we  want  to  specify  as  atomic  nets  in  our 
methodology.  Such  nets  will  use  no  other  net  in  their 
specification  and  so  can  be  considered  as  building  blocks  of 
a  system.  In  general  they  represent  the  elementary  actions  in 
a  system.  The  Abstract  Processor  consists  of  several  such 


elementary  actions  and  to  illustrate  this  idea,  we  will  show 
how  the  actions  of  store  operations  and  fetch  operations  can 
be  described  with  atomic  nets. 

B.  MODELING  OF  MEMORY  AND  REGISTER  ACCESS  TIMING 

The  first  question  we  have  to  ask  when  we  want  to  specify 
the  access  of  memory  or  registers  is  what  kind  of  information 
do  we  have  to  have  available  to  perform  an  access  and  what 
information  we  obtain  after  the  access  has  been  made.  In 
order  to  perform  an  access  the  address  of  the  memory  cell  or 
register  has  to  be  available.  Depending  whether  a  store  or  a 
fetch  has  to  be  performed,  we  either  have  to  provide  a  value 
for  this  process  or  we  obtain  a  value  from  the  process.  Also, 
to  indicate  the  current  contents  of  the  register  or  memory 
cell  we  have  to  indicate  the  process  for  accessing  the  state 
of  the  processor.  In  case  of  a  store  access  we  obtain  a  new 
state  as  the  result  of  the  process  since  the  change  of  a 
memory  cell  or  register  also  changes  the  state. 

At  this  stage  we  have  established  the  components  of  any 
process  dealing  with  the  access  of  memory  or  registers.  We 
anticipate  that  accesses  to  memory  and  registers  will  be  made 
from  various  places  in  the  system,  so  we  provide  a  netlabel 
for  every  entry  and  exit  place.  In  terms  of  our  specification 
methodology  can  now  define  the  entry  and  exit  places  of  the 
subnet : 

-  the  fetching  of  the  contents  of  a  memory  cell  is 
requested  by  providing  message  which  consists  of  the 


memory  address  and  the  state  to  the  following  entry 
place :  req_,fetchm(  net  label  )  Cmemaddr.  state]  { 

-  We  obtain  as  a  result  a  corresponding  message  containing 

the  value  from  the  exit  place: 

avai l_fetcha(net label ) C val 1 } 

-  similarly  we  state  the  entry  and  exit  places  for  fetching 
the  contents  of  a  register: 

req_fetchr(netlabel ) Cregaddr. state] ;  as  the  entry  place 
and  avai  l__fetchr  (net  label  >  C  val  ]  ;  as  the  exit  place 

-  the  storing  of  a  value  into  a  memory  cell  is  requested  by 
providing  a  message  which  consists  of  the  value  to  be 
stored,  the  memory  address  and  the  state  to  the  following 
entry  place:  req_8 torem (net label >( val . aeaaddr. stats] ; 

-  Ue  receive  as  a  result  a  corresponding  new  state  from  the 
exit  place:  avai l_storea(netlabel > [state] ; 

-  similarly  we  define  the  entry  and  exit  places  for  storing 
values  into  registers; 

req_storer (net  label ) C val . regaddr. state] {  as  the  entry 
place  and  aval l_storer (net label > [state] ;  as  the  exit 
place. 

To  show  the  versatility  of  the  proposed  methodology  we 
will  specify  memory  and  register  access  differently:  we  are 
going  to  specify  memory  access  in  a  way  that  allows  only  one 
access  to  one  memory  cell  at  a  time  (an  implementation  for 
this  method  might  be  a  single  memory  unit  allowing  only  one 
access  at  a  time).  On  the  other  hand  we  might  want  to  able  to 
access  registers  in  parallel.  These  requirements  determine 
the  internal  structure  of  resulting  specification. 

Considering  the  above  requirements  on  how  we  have  to 
specify  the  system  we  realize  that  we  have  to  construct  the 
specification  to  deal  with  memory  accesses  and  accesses  to 
each  register  separately. 


As  the  next  step  we  are  going  to  specify  the  memory 
accesses.  Since  we  know  from  our  requirements  that  only  one 
access  at  a  time  is  allowed  to  the  memory  we  have  to  provide 
a  mutual  exclusion  mechanism  in  our  specification  that  makes 
sure  that  the  memory  is  not  accessed  by  more  than  one  request 
at  a  time. 

From  Figure  5.1  we  see  that  from  any  system  location 
indicated  by  a  netlabel  a  message  in  an  entry  place  to 
request  a  memory  access  can  only  trigger  a  transition  to 
activate  the  process  when  the  process  is  available.  Since 
there  is  only  one  empty  message  to  indicate  the  availability 
of  the  net  only  one  request  can  be  honored  at  a  time.  The 
availability  is  restored  when  the  access  is  completed.  Also 
we  see  that  the  internal  places  **processed_f or"  serve  as 
traffic  signs  to  direct  the  results  to  the  appropriate  exit 
places.  Drawing  the  picture  of  the  net  can  be  helpful  to  the 
process  of  specifying  net  just  as  flow  charts  can  be  helpful 
in  programming  tasks,  but  our  intention  is  primarily  to  state 
a  formal  specification.  The  following  is  the  dynamic  part  of 
the  memory  access  specification  expressed  in  precise  syntax: 
entry  places 

req_f etchmCnet labe 1 ) Cmemaddr . state] ; 
req_s torem ( net  1 abe 1 ) [ va 1 . memaddr . state ]  ; 

exit  places 

avail _f etchm (netlabel)Cval]; 
aval  I _s torem ( net  1 abe 1 )[ state ] ; 

internal  places 

access_ava 1  I C ] ; 
f etchra_f  or (netlabel)!!; 
f etchm_act i va ted  Cmemaddr .state ! ; 


f  •tchm_coinp  I  eted  C  va  I  ] ; 
storeni_f  or  (net  I  abe  1 )  [  3  ; 
s torem_act i vated  C  va 1 . memaddr . state  3 ; 
storeni_conpleted[state3 ; 

initial  state 

s>  access_avai 1 C 3 ; 

transitions 

act_fetchm:  Cmeffladdr . state3 , [ 3  ->  [memaddr . state 3 ,[ 3  ; 
per f orm_f etchm :  Cmemaddr . state3  ->  [val3; 
f inish_fetchm;  Cval3,[3  ->  (va]3,[3; 
act_storem:  Cval . memaddr. state3 » C 3  -> 

Cval .memaddr. state 3, C  3 ; 

per f orm_storem :  Cval . memaddr. state3  ->  [state!; 
f inish_storeffl:  [state!, [3  ->  [state!, [3; 

properties 

act_f etchmC req_fetchm( 1 1 } Cm. q3 ,  access_avai 1 [ 3 >  => 
f atchffl_f  or ( 1 1 ) [ 3 , fetchm_acti vated  Cm. q  3 ; 
perform_f etchm ( fetchm_acti vated Cm. q3 )  => 
f etchm_comp 1 etedC  v  3 ; 

f ini sh_f etchm ( f etch_comp I etedC V 3 ,  f etchm_f  or ( 1 1 ) [ 3 )  => 
avai l_f etchmC 1 1 ) [ v3  ,  access_avai 1 C  3 ; 
act_storem<req_storem<  1 1 )  [v.  m.  q! ,  access__avai  1  [  3 )  => 
storera_f or  < 1 1) [ 3 ,  storem_acti vatedC  v. m. q! ; 
perf orm_storem( storera_acti vatedC V. m. q3 )  *> 
storem_comp 1 eted [ql 3 ; 

f  ini8h_storem(storem_compIeted[ql  3 ,  storem_f  or  (  1 1  >  [  3  ) 
avai  l_storem(  1 1 )  [qi  3 ,  access_.avai  I  [  3 ; 

When  we  look  at  the  requirements  of  the  register  accesses 

we  see  that  the  above  design  for  memory  accesses  is  not 

suitable  for  register  access  if  we  want  to  allow  for 

concurrent  access  to  registers.  So  we  have  to  find  a  way  to 

express  the  properties  of  register  accesses.  Looking  closely 

again  at  the  requirements  we  realize  that  each  register  has 

the  same  access  policies  as  the  whole  memory  we  specified 

before.  This  leads  us  to  the  fact  that  every  register  has  to 

have  its  own  specification.  For  the  sake  of  simplicity  let  us 

say  that  our  system  has  three  registers  with  register 


each  for  the  access 


of  a  certain  register.  There  is  one 


problem  though:  whenever  a  register  access  is  requested  from 
somewhere  in  the  system,  the  proper  net  for  the  register  to 
be  accessed  has  to  be  addressed.  So  we  want  to  have  the 
decision  about  which  register  net  is  meant  centralized  in  one 


place  in  the  system.  Therefore  we  employ  some  decision 


Act  atoram  finish  atoram 


Figure  5.1:  Petri  Net  Graph  for  Memory  Access 


mechanism  to  select  the  right  register  access  net.  In  this 
case  the  graph  drawn  out  in  Figure  5.2  of  the  net  might 
confuse  more  than  it  helps-  We  try  to  specify  the  register 


Figure  5.2;  Petri  Net  Graph  for  Register  Access 


access  Just  by  direct  reasoning.  Still,  the  graph  in  Figure 
5.2  illustrates  that,  despite  the  fact  that  each  register  can 
be  accessed  independently  from  the  other  registers,  only 
oneaccess  to  a  register  is  allowed  at  a  time  because  of  the 
separate  ''access_avai  1  ”  places  for  each  register.  These 
places  prohibit  any  access  to  a  register  until  it  is 
ava  •.  1  ab  1  e . 

Again,  we  can  anticipate  that  access  to  registers  will  be 
requested  by  several  locations  in  the  system.  So  we  can  state 
the  entry  and  exit  places  as  we  have  in  the  memory  example. 
Next  we  already  found  out  that  there  three  independent 
register  access  nets  and  we  can  use  again  this  structure  for 
internal  places  and  transitions  we  used  in  the  memory  access 
net.  But  how  do  we  state  that  the  net  for  register  1  is  used 
when  there  is  an  access  request  for  register  1  and  only  this 
net?  The  indication  that  a  certain  register  is  going  to  be 
accessed  is  the  register  address  contained  in  the  request 
message.  Now  instead  of  a  name  of  the  register  address  we 
state  the  actual  value  of  it  when  we  specify  the  properties: 
entry  places 

req_f  etchr (net  1 abe 1 ) C  regaddr . state ] ; 
req_storer ( net  1 abe 1 ) C  va 1 . regaddr . state ] ; 

exit  places 

avai 1 _f etchr (net  I abe 1 ) C  va 1 ] | 
avai l_storer(netlabel )(state] ; 

internal  places 

accessl_avai 1 i 1 ; 

f etchr l_activa ted [ regaddr. state! | 
f etchr l_comp 1 eted  C  va 1 ! ; 
storer l_act i vated [ va 1 . regaddr . state ! ; 
s torer l_comp let ed (state! ; 


access2_avai  HI; 

f etchr2_activated[regaddr . state] ; 
fetchr2_completed[val ] ; 

8torer2_activated[val . regaddr. state] ; 
storer2_coDipleted[state] ; 

access3_aval 1 [ ] ; 

fetchr3_activatedCregaddr. state] ; 
fetchr3_conpleted[val ] ; 
storer3_activatedC val . regaddr. state] ; 
storer3_conpletedCstate] ; 

f etchr_f or (net labe 1 ) C ] ; 
storer__f  or  (net  labe  1 )  C  ]  ; 

initial  state 

->  accessl_avai 1C]; 

->  access2_avai 1 C ] ; 

=>  acces83_avai 1 [ ] : 

transitions 

act_fetchrl:  C regaddr . state] , I  ]  ->  Cregaddr. state] , C ] 
perf ora_f etchr 1 :  C regaddr. state]  ->  tval]; 
f iniah_f etchrl :  [val],[]  ->  Cval],[]; 
act__storer  1 :  Cval .  regaddr.  state]  ,  C  ]  -> 

[ val . regaddr. state]  , C  ]  ; 

perf  oriii_storer  1 :  C  va  1 .  regaddr .  state  1  ->  [state]; 
f inish_8torerl i  Cstatel^C]  ->  [state], []; 

act_fetchr2:  [ regaddr . state ],[ ]  ->  [ regaddr . state ],[  ] 
perf orm_f etchr2:  C regaddr . state ]  ->  [val]; 
f inish_f etchr2:  [val],[]  ->  [val],[]; 
act_storer2:  [ va 1 . regaddr . state ],[ ]  -> 

[val. regaddr . state ] , [ ] ; 

perf orm_storer2 :  [ va 1 . regaddr . state ]  ->  [state]; 
f inish_storer2:  [state], []  ->  [state], []; 

act_fetchr3:  [ regaddr . state] ,[ ]  ->  [ regaddr . state] ,[ ] 
perforin_fetchr3:  [  regaddr .  state  }  ->  [val]; 
f inish_fetchr3:  [val],[]  ->  [val],[]; 
act_storer3:  [ va 1 . regaddr . state] ,[ ]  -> 

[val. regaddr . state ],[] ; 

per  f  orai_storer3 :  [  va  1  .  regaddr .  state  ]  ->  [state]; 
f i ni sh_storer3 :  [state], []  ->  [state], []; 

properties 

act^f etchr 1 ( req_f etchr ( 1 1 )[ 1 . q ] ,  accessi_avai 1 [ ] )  => 
fetchr_for(  IDC],  f  etchrl_aotl  vatedC  1 .  q]  ; 
per  for  iii_f  etchr  1  (  f  etchr  l_acti  vat  edC  1 .  q]  )  => 
f  etchr  i_coinpleted[v] ; 

f i ni sh_f etchr 1 ( f etchl_comp 1 eted  Cv],  fetchr_for(ll)[]) 
avai 1 _f etchr ( 1 1 ) [ v ] ,  access l_avai 1 [ ] ; 


act_storer 1 ( req_storer ( 1 1 ) C V. 1 . ql ,  accessl_avai 1 C ] )  => 
storer_for(ll)[],  storer l_act i vatedC  v. i . q3 ; 
perf orm_storerl ( storer l_acti vat edC v. 1. q] )  *> 
storer  i_corapLi  e ted Cql  3  ; 

f  ini  sh_storer  1  ( storer  l_conipl  etedC  ql  3,  storer  _for(ll)[3) 

=>  avai l_storer ( 1 1 ) Cql 3 ,  accessl_avai 1 [ 3 ; 

act_f etchr2( req_f etchr < 1 1 ) C2. q3 ,  access2_avai 1 C 3 )  => 
f etchr_f  or ( 1 1 ) C  3 , f etchr2_activated[2.  q3 ; 
per  f  orni_f  etchr2(  f  etchr2_activatedC2.  q3 )  => 
fetchr2_completed[v3 ; 

f inish_f  etchr2( f etch2_comp 1 etedC v3  ,  f etchr_f or < 1 1 ) C 3 )  *> 
avai l_f etchr ( 1 1 ) C v3  ,  access2_avai 1 C  3 ; 
act_storer2< req_storer ( 1 1 ) C V. 2. q3 ,  access2_avai 1 C 3 )  => 
storer _for(ll)C3,  storer2_acti vatedC v. 2. q3 ; 
perforra__storer2<storer2_activatedCv.  2.  q3  >  => 
storer2_conpletedCql 3 ; 

f inish_3torer2( storer2_coapl eted [ql 3,  storer_for(ll)C3> 
avai i _storer ( 1 1 ) Cql 3 ,  access2_avai 1 [ 3 ; 

act_fetchr3( req_f etchr ( 1 1 ) C3. q3 ,  access3_avai 1 C 3 >  »> 
f etchr _f or ( 1 1 ) [ 3  ,  f etchr3_actlvated[3. q3 ; 
perf orB_fetchr3(fetchr3_activatedC3.  q3 )  => 
fetchr3_coinpletedCv3 ; 

f inish_f etchr3( f etch3_conpletedC V 3 .  f etchr_f or ( 1 1 ) C 3 )  => 
aval I_f etchr ( 1 1 ) Cv3 ,  access3_avai 1  £  3 ; 
act_8torer3< req_storer < 1 1 ) £ V. 3. q3 ,  access3_avai 1 [ 3 >  => 
storer_f or ( 1 1 ) C  3 ,  storer3_actl vatedC  v.  3.  q3 ; 
perf or m_storer3( storer 3_activa ted Cv. 3. q3 )  «> 
storer3_compl eted Cql 3 ; 

f inlsh_storer3( s torer3_compl etedCql 3,  storer _for(ll)C3) 

=>  avai l_storer ( 1 1 ) Cql 3,  access3_avai i C 3 ; 

Ue  see  that  even  specifications  of  simple  resources 

become  large  and  complex  and  the  drawing  the  net  is  even  more 

complex.  Here  we  realize  the  real  benefit  of  the  introduction 

of  subnets:  once  these  subnets  are  specified  we  can  use  their 

properties  everywhere  in  our  system  simply  by  stating  the 

entry  and  exit  places  of  the  subnets  in  the  net  we  want  to 

specify.  Those  nets  using  subnets  are  actually  extensions  of 

the  subnets.  The  next  section  will  illustrate  these  facts  in 


detai  1  . 


C.  MODELING  OF  INSTRUCTION  FETCH  AND  EXECUTION  TIMING 


From  the  static  specification  of  the  Abstract  Processor 
we  see  that  there  are  two  operands  "prog”  and  "exq"  which  are 
responsible  for  the  process  of  executing  programs.  The 
process  is  kept  going  by  corecursive  calls  between  those  two 
operators. 

Even  though  those  two  processes  are  very  closely 
connected  by  corecursive  calls  we  want  to  consider  them 
separately  and  start  with  specifying  the  "exq"  process. 

The  "exq"  process  needs  information  about  the  instruction 
to  be  executed,  the  current  memory  address,  and  the  state  of 
the  processor.  After  the  process  has  finished  it  returns  the 
new  state.  This  determines  the  contents  of  the  messages  the 
entry  and  exit  places  of  this  net  have  to  accommodate.  Still 
we  have  to  decide  what  kind  of  execution  unit  we  want  to 
specify.  Ue  want  to  specify  that  only  one  execution  unit  can 

I  be  performed  at  a  time.  This  means  that  we  have  to  provide 

I 

mutual  exclusion  for  the  use  of  this  net.  We  can  do  this  the 
same  way  as  we  provided  for  memory  accesses.  We  can 
accomplish  that  by  providing  a  distinct  entry  place  and  exit 
place  indicated  by  netlabels.  Now  we  are  in  a  position  to 
specify  the  entry  and  exit  places: 

I 

I 

I  -  req_jexq(net  label )  C  instr.memaddr.  state] ;  as  the  entry 

!  place 

-  aval l_exq(net label > Cmemaddr. state] )  as  the  exit  place 

At  this  point  we  have  to  look  closely  at  the  actions  an 

I 

!  execution  on  an  instruction  has  to  accomplish:  retrieval  of 


information  from  the  instruction. 


about  register  and  memory 


addresses  of  operands,  and  about  the  operation  to  be 
performed,  accesses  to  the  operands,  application  of  the 
operator,  and  calculation  of  the  address  of  the  next 
instruction  to  execute.  We  see  now  that  the  previous 
specifications  for  memory  and  register  accesses  will  come  in 
handy  when  have  to  specify  these  accesses  in  the 
specification.  Also  we  assume  for  this  specification  that 
there  are  nets  for  the  retrieval  of  operands  and  operators 
from  the  instruction,  the  application  of  operands  and 
calculation  of  the  next  memory  address. 

The  next  issue  we  have  to  address  is  the  fact  that 
different  instructions  have  to  be  executed  differently.  Here 
a  decision  mechanism  similar  to  the  one  we  introduced  to 
access  a  specific  register  can  help  us  to  make  the 
specification  structured  and  understandable.  The  mechanism  we 
introduce  here  has  to  recognize  from  the  instruction  part  of 
the  message  which  execution  is  requested  and  has  to  direct 
the  path  within  the  speci f icat icn  to  the  appropriate  part  of 
the  specification.  In  the  formal  specification  we  indicate 
this  explicitly  by  the  contents  of  the  Instruction  part  of 
the  request  message. 

In  the  following  we  show  some  representative  examples  of 
the  execution  specifications  of  different  instructions.  Their 
graphs  are  depicted  in  Figures  5.4  and  5.5  and  illustrate 


clearly  the  simplification  obtained  by  the  use  of  predefined 

subnets. 

entry  places 

req_exq (net  1 abe 1 ) C instr . memaddr .  state  1 ; 
exit  places 

aval l_exq(netlabel ) Cmemaddr. state] ; 


internal  places 
exq_avai 1 C ] { 
exq_f or (net  1 abe 1 ) C ] ; 

exq_aonad_act ivatedCstate] ; 
exq_aonad_fetchC  state  1 ; 
exq_aonad_apply [state] ; 
exq_monad__storeC  ]  ; 

exq_mov_r_r_activatedCstate] ; 
exq_aov_r_r_performt  state! ; 
exq_mov_r_r_storeC ] ; 

initial  state 

=>  exq_availC]; 

transitions 

actl vate_exq_monad:  C instr. memaddr. state] ,[ ]  -> 
[state ], Cinstr], Cinstr], Cinstr], Cmemaddr ] ; 
start_exq_monad :  C state] regaddr ] ,  -> 

C  state ] I C  regaddr . state] ; 
app 1 y_exq_monad :  C state }, [operator ],[ va 1 ]  -> 
[state], [operator. val ]; 
store_exq_monad :  [ state ],[ va 1 ],[ regaddr ]  -> 

[ ] , [ va 1 . regaddr . state ] ; 
f ini sh_exq_monad :  [], [state! , Cmemaddr ]  -> 

Cmemaddr . state ] ; 

acti vate_exq_mov_r_r ;  [ instr. memaddr . state! , C !  -> 
[state], [instr!, Cinstr], C  memaddr ! ; 
start_exq_aov_r_r :  [ star t ],[ regaddr !  -> 

[state! , [ regaddr. state! ; 
store_exq_mov_r_r :  [state! ,[ regaddr !, C va I !  -> 

[ ] , [ va I . regaddr . state ! ; 
f lnish_exq_mov_r_r I  [],[ state !, [memaddr !  -> 
Cmemaddr . state ] ; 

properties 

activate_exq_monad(exq_aval 1 C ! , 

req_exq ( I ) C  monad (o.ri.r2).m.q})  => 
exq_f  or (!)[],  exq_raonad_act ivatedCq!, 
req  operator(ll)[ monad (o. r 1 . r2) ! , 


raq_operandl (12) C monad (o. r 1 . r2) ] , 
req_operand2( 13) Cmonad<o. rl. r2) ] , 
r«q_nextnemaddr ( 1 4) Cm! ] 
star t_exq_monad ( exq_monad_act i vated [ q  J , 

aval  1 _operandl ( 1 1 ) [ rl ] )  ->  exq_monad_f etchC q 3 , 
roq_f  etchr (15)[rl.q3; 

•PPly_®X91_®o»'»d(exq_monad_fetchtq3,  aval  l_f etchr (  15)Cv], 
aval l_operator ( 1 1 ) Co] )  =>  exq_aonad_apply Cq] , 
req_apply_mop( 16) Co. v] ; 

8tore_exq_aonad (exq_monad_app)yCq  3 , 

aval l_apply_mop( 16) C vl 3 ,  aval  1 _operand2( 1 3) C r23 )  => 
exq_aonad_8toreC  3 ,  req_storer (17)Cvl.r2.q]; 
f ini sh_exq_aonad  <exq_monad_s tore C  3,  avail_storer(17)Cql], 
aval l_nextfflenaddr ( 14) Cml 3 )  «>  aval  1 _exq( 1 ) Cal . ql 3 ; 

act!  vate__exq_inov_r_r  'exq_aval  1  C  3, 

req_exq( 1 ) Caov_r_r (rl,r2).m.q3)  *> 
exq_mov_r_r_act 1 va  tedC  q  3 , 
req_operandl  (11)  Coiov_r_r  <  r  1 ,  r2)  3 , 
raq_operand2( 12) Cmov_r_r(rl, r2) 3 , 
req_nextneaaddr ( 13) Cm] t 
star t_exq_mov_r_r (exq_mov_r_r_actl vated C  q  3 , 
aval  1  _operandl ( 1 1 ) C r 1 3 )  -> 

exq_mov_r_r_perf ormCq3 ,  req_f etchr ( 1 4) C  r 1. q  3 ; 
atore_exq_mov_r_r  <exq_mov_r_r_perf ormCq] , 

aval l_fetchr< 14) Cv],  aval l_operand2( 1 2) C r2 3 )  => 
exq_mov_r_r_8toreC  3 ,  req_8torer Cv.  r2.  q3 ; 
f inlsh_exq_mov_r_r (exq_mov_r_r_storeC  3,  aval l_storerCql 3, 
aval  1 _nextaemaddr < 1 3) Cml 3 )  => 
aval l_exq( 1 ) Cml .  ql 3 ; 

The  above  two  examples  show  the  specification  of  the 
execution  of  a  monadic  instruction  and  of  a  move  instruction. 
We  have  used  the  previously  specified  register  access 
("fetchr"  and  "storer")  to  fetch  the  contents  of  a  register 
and  to  store  a  value  into  a  register.  The  way  we  used  them 
was  that  we  stated  their  entry  and  exit  places  at  the 
appropriate  locations  in  the  description  of  the  properties  of 
our  execution  specification.  In  the  same  way  we  invoked  the 
specifications  of  "nextmemaddr”,  "apply_mop",  "operandl", 
''operand2'’  and  "operator"  which  for  this  example  we  assumed 
to  be  defined  . 


s 


We  want  to  eaphasize  at  this  point  that  the  stated 
properties  of  the  given  examples  are  not  the  only  way  the 
execution  could  be  specified:  we  are  following  the  philosophy 
that  as  soon  as  the  information  is  available,  the  possible 
requests  are  made  based  on  the  information.  In  a  real 
specification  other  considerations  may  have  priority,  but  our 
intention  is  to  show  how  this  can  be  accomplished  using  the 
methodo logy. 

The  next  part  of  the  specification  is  to  state  the  "prog" 
part  and  to  connect  it  with  "exq”  in  a  way  that  illustrates 
the  corecursiveness  of  their  interconnection.  Since  we  have 
already  modeled  the  ’’exq"  part  as  a  process  taking  an 
instruction,  a  memory  address  and  the  state,  and  provides  a 
new  memory  address  and  a  new  state,  we  want  this  as  a  subnet 
in  our  "prog"  specification.  When  we  look  again  at  the  static 
specification  of  "prog"  of  the  Abstract  Processor  we  realize 
that  this  process  needs  a  memory  address  and  the  state  to  get 
started,  i.e.  the  same  information  as  "exq"  provides  as 
output.  This  fact  leads  to  the  idea  of  a  loop  in  requesting 
"prog":  when  "prog"  has  performed  its  initial  tasks  and  has 
invoked  "exq"  it  is  in  the  situation  of  requesting  itself 
again  as  soon  as  the  result  of  "exq”  is  obtained.  This  idea 
will  work  nicely  once  the  process  is  started,  but  how  do  we 


get  this  process  running?  Here  we  can  claim  that  the  initial 
request  has  to  come  from  the  outside  world  (imagine  a 
possible  implementation  as  an  on-switch  at  the  machine  which 
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resets  the  state  and  sets  the  program  counter  to  a  predefined 

initial  value).  We  want  to  specify  this  process  as  a  single 

control  unit  and  that  this  is  the  major  process  in  the 

system.  The  following  is  a  possible  specification  of  "prog" 

(see  also  Figure  5.5): 

entry  places 

req_prog  Cmemaddr . state  1 ; 

internal  places 
prog_avai 1 C ] ; 

prog_f  etchCmemaddr . state) ; 
prog_i  ns tr Cmemaddr . state) ; 
prog_per f ormC ) 

initial  state 

=>  prog_avai 1 [ 1 ; 

transitions 

acti vate_prog t  C ), Cmemaddr . state)  -> 

Cmemaddr. state) , Cmemaddr. state) ; 
get_lnstr_prog:  Cmemaddr . state ), C va 1 )  -> 

Cmemaddr. state), Cval ) ; 
perf orm^prog:  Cmemaddr . state) , C instr )  -> 

C ) , C instr. memaddr. state) ; 
finish_prog:  C ), Cmemaddr . state)  -> 

C ) , Cmemaddr. state) ; 

properties 

acti vate_prog(prog_avai 1 C ) ,  req_progCm. q) )  »> 
prog_f etchCm. q) ,  req_f etchm( 1 1 ) Cm. q) ; 
get_instr_prog(prog_actlvatedCm. q) ,  aval l_fetchm( 1 1 ) Cv) ) 
=>  prog_instr Cm. q) ,  req_atomof instr ( 1 2) C v ) ; 
perform_prog(prog_instr Cm. q) , 

aval  1 _atomof ins tr ( 1 2) C i ) )  => 
prog_perf ormC ) ,  req_exq( 13) C i . m. q) ; 
f inish_prog(prog_performC ),  aval  1  _exqCml . ql 1 )  => 
prog_avai 1 C ) ,  req_progCral . ql ) ; 

The  declaration  of  "req_prog"  as  an  entry  place  models 

our  previous  stated  connection  to  the  outside  world.  Note 

that  this  specification  in  the  form  presented  could  not  be 

used  as  a  subnet  since  no  exit  place  has  been  declared.  The 
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following  Figure  5.5  shows  how  this  specification  is  drawn  as 
a  net. 

D.  MODELING  OF  INTERRUPTS 

The  above  specifications  of  "exq"  and  "prog"  and  their 
interconnection  in  their  current  form  does  not  provide  for 
any  recognition  and  processing  of  interrupts.  This  chapter  is 
to  show  one  way  how  interrupts  could  be  handled  using  our 
specification  methodology. 

As  always  the  first  step  is  to  state  the  requirements  for 
the  process  of  interrupt  handling.  Ue  want  to  look  at 
interrupts  as  a  signal  which  comes  either  from  outside  or 
inside  the  system  on  which  the  current  running  program  is 
interrupted  and' a  handler  program  at  a  predefined  location  is 
started.  After  the  completion  of  the  handler  the  execution  of 
the  interrupted  program  is  resumed,  therefore  we  need  to  save 
the  memory  address  of  the  interrupted  program.  Also  we  want 
the  invocation  of  the  interrupt  handler  only  to  happen  at  a 
defined  state,  i.e.  between  the  completion  of  the  execution 
of  one  instruction  and  the  fetching  of  the  next  instruction. 
Another  requirement  is  that  the  interrupt  handler  acts  on  a 
single  interrupt  only  one  time,  so  that  a  following  interrupt 
signal  can  be  interpreted  as  another  interrupt.  In  the 
following  specification  we  assume  that  there  is  a  dedicated 
stack  in  the  system  on  which  the  current  memory  address  of 


the  running  program  can  be  saved.  Also,  for  simplicity 

reasons  we  allow  only  one  type  of  interrupt,  i.e.  the  handler 

has  to  determine  the  source  of  the  interrupt  by  software.  The 

following  is  one  way  to  specify  the  above  requirements  (also 

see  F i gure  5.6): 

entry  places 

req_progCmemaddr .  state! ; 

internal  places 
prog_avai I C 1 ; 

prog_f  etchCmemaddr. state! ; 
prog_instr [ memaddr .state ! ; 
prog_per f ormi ! 
prog_checkCmemaddr. state! ; 
prog_saveC ! ; 

initial  state 

»>  prog_aval 1C!; 

transitions 

acti vate_prog :  C !, Cmemaddr. state!  -> 

C memaddr. state! , Cmemaddr.  state! ; 
get_lnstr_prog:  Cmemaddr . state J , C va 1 !  -> 

Cmemaddr. state! , C val ! ; 
perf orm_prog :  C memaddr . state! , C instr !  -> 

C!,Cinstr. memaddr .state  !  ; 
finish_prog:  C !, Cmemaddr . state !  -> 

C memaddr . state !, C  ! ; 

normal_jprog:  Cmemaddr.  state!  ,  C  3  -> 

C ! , Cmemaddr. state! ; 
ltrpt_prog : Cmemaddr, state! , C !  -> 

C !, Clnstr. memaddr. state! ; 
f in_int_prog :  C !, C memaddr . state !  -> 

C ! , Cmemaddr. state! ; 

properties 

actlvate_prog(prog_avai 1 C !,  req_progCm.  q! )  *> 

prog_f  etchCm. q ! ,  req_f etchm( 1 1) Cmemaddr. state! ; 
get_instr_prog ( prog_act i vatedCm. q!  ,  aval l_fetchra<ll)Cv!) 

=>  prog_instr Cm. q! ,  req_atomof ins tr ( 1 2 ) C v ! ; 
per f orm_prog ( prog_instr  Cm. q ! , 

aval  1 _atomof instr ( 1 2) C i ! }  => 
prog_per f ormC !  ,  req_exq( 13) C i . m. ql ; 
f inlsh_prog(prog_performC !,  aval  1 _exqCmi  .  ql ! )  => 
prog_check C ml .  ql ! ,  req_checkC!; 


noriBal_prog ( prog_check[ml .  ql  ] ,  aval  I  _nornia  1  C  ]  )  => 
prog_avai 1 C ] ,  req_progCnl . ql 1 
i trpt_prog ( prog_check Cml . ql ] .  aval  1  _intrpt [ 3 )  *> 

prog_saveC 1 ,  req_exqE  Jsr< lnt_addr , sys^stk) .  ml .  ql 3 ; 
f in_int_prog(prog_saveC 3 ,  aval l_exqCm2. q23 )  => 
prog_avai 1 C 3 ,  req_progCffl2.  q23 ; 

The  above  interrupt-sensitive  specification  of  "prog"  is 
very  similar  to  the  former  specification  of  "prog"  which  did 
not  provide  for  interrupt  handling  (compare  Figure  5.5  and 
Figure  5.6).  The  major  difference  is  that  an  "external  agent" 
is  invoked  as  soon  as  the  execution  of  the  instruction  is 
completed.  This  Agent  sends  a  message  to  one  of  its  output 

places  to  show  that  either  an  interrupt  is  present  or  not. 

This  construct  ensures  two  properties:  first,  the  External 
Agent  is  responsible  for  clearing  the  interrupt  signal  after 
it  has  recognized  it  so  that  an  interrupt  is  only  honored 
once;  second,  the  presence  of  an  interrupt  has  priority  over 
the  normal  way  of  execution  of  a  program.  Once  an  interrupt 
has  been  detected  by  the  Agent  and  its  appropriate  output 

place  has  been  provided  with  a  message  the  "prog"  process  can 

continue  and  it  will  place  the  current  memory  address  on  a 
specified  system  stack  by  executing  a  "push"  instruction  and 
will  start  a  new  cycle  at  the  system  interrupt  handler 
address.  Since  the  interrupt  handler  is  by  itself  a  loaded 
user  program  is  responsible  for  saving  the  necessary  register 
contents  and  for  restoring  those  registers  and  the  saved 
memory  address  from  the  system  stack  when  it  finishes. 
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E.  EXECUTION  OF  PROGRAMS 

The  question  to  be  asked  now  is:  how  will  the  proposed 

specification  methodology  show  the  timing  of  the  execution  of 

programs?  As  an  example,  let  us  consider  the  following  simple 

program: 

1000:  1 
1001 :  2 

2000:  M0V_M_R  1000, rl 

2001:  M0V_M_R  1001, r2 

2002:  ADD  rl,r2,r3 

2003:  M0V_R_M  r 3, 1002 

2004:  STOP 

The  above  program  retrieves  the  values  "1"  and  "2”  from 
memory  addresses  1000  and  1002  into  registers  "rl"  and  "r2", 
adds  them  together,  with  the  result  in  ”r3",  and  than  moves 
this  result  into  memory  address  1002.  At  the  top  level  of  the 
specification  there  is  the  "prog"  net.  With  the  start  of  this 
program  it  receives  the  "req_progC2000. ql 1 "*  message  from  the 
outside.  It  retrieves  the  instruction  contained  in  memory 
address  2000  and  invokes  the  "exq"  net  with  the  message 
"req_exqC instr . 2000.  ql 1 " .  Inside  the  "exq"  net  the  "external 
agent"  determines  the  appropriate  net  to  process  the 
instruction,  here  the  "mov_m_r"  net,  and  enters  this  net. 
After  the  completion  of  "exq",  "prog"  finishes  with  a  message 
"req_progt2001 . q2] "  to  itself  where  the  "2001"  and  q2  were 
obtained  from  the  execution  of  "exq".  At  this  point  "prog" 
starts  all  over  again  and  finishes  with  the  message 
"req_progC2002. q3]".  This  repeats  until  the  "stop" 

*Netlabels  are  omitted  for  simplicity 


instruction  is  executed  and  results  in  termination  of  the 

process.  Inside  the  invocations  of  the  "exq"  net  there  are 

several  uses  of  the  nets  to  access  memory  and  registers  as 

well  as  to  process  "nestmemaddr”. 

The  following  shows  the  major  messages  with  their 

included  data  that  are  exchanged  during  the  course  of  the 

execution  of  the  program  (not  necessarily  in  the  order  as 

they  might  occur): 

req_progC2000, qi ] 

req_f  etchmt2000, ql 1 
avail _fetchm["MOV_M_R  1000, rl"3 
req_atomof instr£"MOV_M_R  1000, rl"3 
aval l_atomof instr tmov_m_r  (1000, rl ) ] 
req_exqCmov_m_r ( 1000, rl ) . 2000. ql 1 
req_operandl Cmov_m_r  ( 1000, r 1 ) ] 
aval l_operand2C 10003 
req_operand2£mov_m_r  ( 1000, r 1 ) 3 
aval l_pperand2C  r 1 3 
req__f  etchmC  1000.  ql  3 
aval l_fetchmC 1 3 
req^storertl. rl.ql3 
aval I_storerCq23 
req_nextmemaddr  C20001 
aval  1 _nextmemaddr  C2001 3 
aval  I _exq[2001 . q2  3 
req_progC2001 ,  q2  3 

req_f etchmC  2001 , q23 
aval  l_fetchmC’'MOV_M_R  1001,  r2" 3 
req_atomof instr  C ”M0VJM_R  1001 , r2" 3 
aval  1 _atomof instr  Cmov_m_r ( 1001 , r2) 3 
req_exq[raov_m_r ( 1001 , r2) . 2001 . q23 
req_operandl Cmov_m_r ( 1001, r2) 3 
aval l_operand2C 1001 3 
req_operand2Cmov_m_r (1001, r2) 3 
aval  1 _operand2C  r2  3 
req_f  etchmC 1001 . q23 
aval l_fetchm[23 
req_storer  C2.  r2.  q21 
aval l_storer [q33 
req_nextmemaddr  C2001 3 
aval  1 _nex tmemaddr  C  20023 
aval  1 _exq [ 2002. q3  3 
req_prog[2002. q33 

req_f etchroC2002,  q33 


aval  1  __fetchfflC  "ADD  rl,r2tr3"] 
req_atoBof instr C "ADD  rl,r2,r3"] 
aval  l__atomof  instrCdyadr  (add,  rl,  r2,  r3}  ] 
req_exq[ dyad (add, rl,  r2, r3) .2002. q3] 
req_operandl C dyad (add, rl,r2,r3)] 
aval  1 _operandl [ r 1 ] 
req_operand2[ dyad (add, r 1 , r2, r3 ) 3 
aval  1 _operandl [ r2] 
req_operand3Cdyad (add, rl,r2,r3>] 
aval l_operand3Crl] 
req_operator [dyad(add, rl, r2, r3> ] 
aval  I .operator [add 3 
roq_f etchrCrl. q33 
aval l_f etchr [ 1 3 
req_f  etchr C  r2. q31 
aval l_f etchr[23 
req.appl ydopCadd. 1.23 
aval l_apply_dopC33 
req.storer t3.  r3.  q33 
aval l_storer[q43 
req.nextfflenaddr C20023 
aval l.nextmenaddr [20033 
aval l_exq[2003. q43 
reqjprog[2003, q43 

req_f  etchmC2003, q4  3 
aval l.fetchm["M0V_R_M  r3,1003"3 
req.atomof instr C "MOV.r.m  r3, 1003" 3 
aval l.atonof instr Cmov.r_m(r3, 1003) 3 
roq_exqtaiov_r_iB(  r3,  1003) .  2003.  q43 
req.operandl  Cmov_r_m(r3, 10()3)  3 
aval  1  _,operand2C  r33 
req_operand2Cmov_r_in(r3, 1003)  3 
aval l_operand2C 10033 
req_f  etchr  C  r3. q4  3 
aval i_fetchoC31 
req.storer [3. 1003. q43 
aval l.storerCqSl 
req.nextmemaddr [20033 
aval  l_nextinemaddr[2004] 
aval l_exq[2004. q53 
req_j>rog[2004.  q5  3 

req_f  etchin[2004,  q5  3 
aval  l_fetchin["ST0P") 
req.atomof instr [ "STOP" 3 
aval  1 .atomof instr [ stop! 
req_exq[ stop. 2003. q43 
aval l_exq[ . q43 


With  the  appropriate  tools  to  track  certain  Messages  and 
their  contents  one  is  able  to  take  snapshots  during  the 
course  of  the  execution  to  determine  the  timing  within  the 
execution. 


VI .  SUMMARY  AND  CONCLUSION 


The  intention  of  this  work  has  been  to  present  a 
methodology  to  specify  timing  in  computer  systems  with  strong 
emphasis  on  the  issues  of  portability  and  reusability.  The 
work  has  been  also  influenced  by  the  goal  to  pursue  a 
practical  viewpoint  for  dealing  with  computer  resources.  In 
describing  the  essential  properties  of  timing  between 
abstracted  computer  resources,  it  has  been  possible  to  state 
the  required  timing  in  a  system  in  an  exact  and  rigorous  way. 
As  a  first  result  of  this  work  it  has  been  pointed  out  that 
the  attempt  to  specify  the  time  behavior  of  a  computer  system 
without  having  a  formal  specification  of  the  static  behavior 
of  the  system  will  lead  to  inconsistencies  and  errors.  We 
view  the  timing  specification  as  an  extension  of  the  static 
specification  (the  system  functionally)  to  a  complete 
specification  (the  system  functionally  and  dynamically). 

A.  ADVANTAGES 

This  methodology  is  based  on  Petri  Nets  and  their 
underlying  theory.  Since  Petri  Nets  are  an  accepted  and 
commonly  used  tool  in  a  variety  of  applications  one  familiar 
with  Petri  Nets  will  have  almost  no  problems  understanding 
the  methodology.  During  the  course  of  this  research  a  number 
of  distinct  advantages  have  been  recognized: 


1 .  Ability  to  State  Asynchronuous  Timing 
Asynchronuous  timing  in  a  system  is  the  most  common 

timing  method  in  any  computer  system,  be  it  the  reaction  on 
the  completion  of  some  task  or  dealing  with  an  external 
interrupt.  The  examples  presented  during  this  work  show  very 
clearly  that  every  event  displays  asynchronuous  timing  since 
it  reacts  on  certain  holding  conditions  whenever  they  might 
be  true.  By  stating  events  and  their  connected  places  we  can 
describe  the  asynchronuous  timing  easily. 

2.  Ability  to  Show  Dataflow  n  a  System 

The  combined  consideration  of  timing  and  dataflow  in 
a  system  has  been  accomplished  by  changing  the  original  token 
meaning  of  Petri  Nets  into  a  data  carrying  message.  This 
enables  the  methodology  to  exhibit  currently  available  data 
at  any  stage  of  the  process. 

3.  Ability  to  Model  Concurrency 


The  inherent  ability  of  Petri  Nets  to  model 
concurrency  by  activating  several  places  as  the  result  of  a 
transition  is  available  in  this  work  and  provides  a  useful 
construct. 


4.  Ability  to  Model  Mutual  Exclusion 

As  it  was  shown  in  different  examples  it  was  possible 
to  model  mutual  exclusion  simply  by  incorporating  a  structure 
of  control  places  into  nets  which  allow  only  one  access  to 
the  nets  or  to  of  parts  of  the  nets  at  a  time. 
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B.  DISADVANTAGES 


The  disadvantages  of  this  methodology  can  be  based  on  the 
properties  of  Petri  Nets  and  the  intended  accuracy  of  the 
sped  f  i  cat  ions . 

1 .  Comp  1  ex i ty 

The  given  examples,  though  very  simple  and  small  in 
their  nature,  exhibit  a  large  complexity  in  stating  the 
specification.  This  complexity  is  largely  due  to  the  details 
involved  in  the  timing  of  systems  and  also  to  the  attempt  to 
handle  data  in  the  timing.  The  syntax  presented  is  only  one 
way  of  representing  formal  timing  specification  and  it  is 
very  tedious  for  the  user  to  deal  with  it,  therefore  a  future 
implementation  should  provide  an  user  interface  which  is  easy 
to  interact  with,  preferably  in  a  graphical  environment. 

2.  Difficulty  to  Model  Decisions 

Petri  Nets  by  their  nature  are  non-deterministic  and 
so  the  specification  methodology  presented  suffers  from  this 
disadvantage  when  we  are  forced  to  model  decisions.  The  idea 
introduced  of  "external  agents"  helps  to  deal  with  this 
prob 1 em. 

C.  FURTHER  RESEARCH  TOPICS 

This  work  has  been  a  basic  step  in  showing  the 
possibility  of  specifying  the  time  behavior  of  a  computer 
Jsystem.  As  further  research  topics  we  suggest  the  following 


areas : 


Autonation  of  this  methodology  to  hide  the  complexity  of 
the  specification  from  the  user  by  providing  a  graphical 
interface 

Provision  of  automated  features  which  allow  the  user  to 
make  inquiries  about  the  specified  system,  e.g.  existence 
of  deadlocks,  history  of  invocations  of  certain  subnets, 
trace  of  certain  messages,  etc. 

Development  of  tools  which  are  able  to  analyze  and 
compare  the  performances  of  different  specifications 

Research  in  the  area  of  timed  Petri  Nets  where  actions 
can  be  specified  to  be  performed  within  a  specified  time 

Application  of  this  methodology  in  the  area  of  the  newly 
developed  computer  systems  using  transputers  and  their 
programming  language  OCCAM 
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APPENDIX  A;  EDITED  STATIC  SPECIFICATION  OF 


THE  ABSTRACT  PROCESSOR 


This  edited  specification  of  an  Abstract  Processor  is 
based  on  the  work  of  Yurchak  (1984).  It  uses  an  improved 
syntax  of  Davis  and  Yurchak  (1985)  which  is  considered  more 
meaningful.  Also,  some  minor  changes  to  correct  errors  have 
been  made.  The  specification  consists  of  two  parts:  the 
replacement  statement  which  provide  a  shortcut  for  stating 
frequently  used  properties,  and  the  specification  of  the 
various  resources. 


rep  1  ace (X,  S ) 

"equivrel (X, S) ; " 

with 

”X ( i , i )  =  true ( ) ; 

X(i, j)  =  X( j,  i  )  ; 

imp  I i es ( and (X ( i , j ) , X ( j , k ) ) , X ( i  ,  k ) )  =  true();" 

replace(X, S) 

"r ef 1  ex i ve ( X , S  )  ;  " 

with 

"X( i , i )  =  true( ) ; " 

rep  1  ace ( X,  S ) 

"commutat i ve ( X , S  )  ;  " 

with 

"X(i, j)  =  X( j,  i  )  ;" 

rep  1  ace ( X, S ) 

”transitive(X,S) 

with 

"impl  ies  (and(X(  i  ,  j  )  ,  X(  j  ,  k  )  )  ,  X(  i  ,  k  )  )  =  trueO;" 

rep  1  ace ( X, S ) 

"associative(X,S) 

with 

”X( i , X( j , k) )  =  X(X( i , j ) , k) ; " 

rep  I  ace ( X,  S ) 

”irreflexive(X,S) 


”X( i , i )  =  fal se( ) ; " 

replace(X, S) 

"symmetr ic (X, S) ; ” 

with 

"Impl  ies(X(  i,  j  )  ,X(  j  ,  1  )  )  =  trueO;" 

replaceCX, S) 

"ant i symmetr i c ( X, S ) ; " 

with 

"Impl ies(and(X( i , j ) , X ( j , i ) ) , ( i == j ) ) 

rep  1  ace ( S , T ) 

"i dopers (S, T) ; " 

with 

"startT:  ->  S; 
nextT:  S  ->  S; 
prevT:  S  ->  S; 
eqT:  S, S  ->  bool j " 

replace (S, T) 

" i dax i oms ( S , T) ; " 

with 

"prevS ( star tT ( ) )  is  undefined; 
prevS ( nex tS (  i  )  )  =  i; 
if  i  !=  startTO 
then 

nextS ( prevS ( i ) )  =  i; 
endl f ; 

equivrel (eqS,S) 

rep  1  ace ( S ) 

"typingopers(S) 

with 

"typeS;  ->  type; 
atomofS:  va 1  ->  S; 
va lofS;  S  ->  val;" 

rep  1  ace ( S ) 

"typingaxioms(S) ;" 

with 

"whattype C va 1  of S ( t ) )  =  typeS(); 
atomof S ( va 1  of S ( t ) )  =  t; 

if  whattype(v)  =  typeS() 
then 

va 1  of S ( atomof S ( V ) )  =  v; 

else 

atomofS(v)  is  undefined; 
endif ; " 

rep  1  ace ( S , T ) 


=  true ( ) 
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re  1 op( S, T )  ; 


» 


with 

"app 1 yrop ( ST ( ) , vl , v2)  = 

valofbool (TS (atomof S (vl),atomofS(v2) ) ) 

replace (S) 

" i sops ( S ) ; " 

with 

"if  whattype(v)  =  typeSC) 
then 

app 1 ybop ( i sS ( ) , V )  =  va 1  of boo  1 ( true ( ) ) ; 

e  1  se 

app 1 ybop ( i sS (), V )  =  va 1  of boo  1 ( f a  1 se ( )  )  ; 
end  if;" 

repIace(S, T) 

"stateax i oms ( S , T ) ;" 

with 

"f etchS (a, ini tam( ) )  is  undefined; 
stores ( f etchS ( a, q ) , a, q )  =  q; 

imp  1 i es ( eqT ( al , a2 ), fetchS (al , stores ( V , a2, q ) )  =  v 
=  true ( )  ; 

impl ies(not(eqT(al,a2) , fetchS(al, storeS(v,a2, q) ) 
f etchS(al ,  q) )  =  true();" 


Resource  boolean  is 

Extension  of 

Operand  Types 
boo  1  ; 

Operators 

true :  ->  boo  1 ; 
false:  - >  boo  1  ; 
not:  bool  ->  bool; 
and:  bool, bool  ->  bool; 

Derived  Operators 

or:  bool, bool  ->  bool; 
implies:  bool, bool  ->  bool; 

Derived  Definition 

or(bl,b2)  =  not ( and (not ( bl ) , not ( b2 ) ) ) ; 
imp  1 i es ( b 1 , b2 )  =  no t ( and ( b 1 , no t ( b2 ) ) ) ; 

Properties 

false  =  not(true()); 

not(not(b))  =  b; 

and (true(),b)  =  b; 

and ( f a  1 se ( ) , b )  =  false(); 


commutat 1 ve( and, bool); 
end  boolean; 


Resource  natural  is 

Extension  of 
boo  1 ean 

Operand  Types 
nat ; 

Operators 

zeronat:  ->  nat; 
prednat:  nat  ->  nat; 
succnat:  nat  ->  nat; 
sumnat:  nat, nat  ->  nat; 
mltnat:  nat,nat_->  nat; 
divnat:  nat, nat  ->  nat; 
eqnat:  nat, nat  ->  bool; 
gtnat:  nat, nat  ->  bool; 

Derived  Operators 

Itnat:  nat, nat  ->  bool; 
genat:  nat, nat  ->  bool; 
lenat:  nat, nat  ->  bool; 
nenat:  nat, nat  ->  bool; 

Derived  Definition 

ltnat(n,m)  =  no t < or ( gtnat ( n, m ) , eqna t ( n , m ) )  ) 
genat(n,m)  =  not ( 1 tnat ( n, m ) ; 
lenat(n,m)  =  not ( gtnat ( n, m )  ; 
nenat<n,m)  =  not ( eqnat ( n, m ) ; 

Properties 

prednat (zeronat () )  is  undefined; 
prednat ( succnat ( n ) )  =  n; 
succnat ( prednat ( n ) )  =  n; 
sumna t ( n , zer ona t ( ) )  =  n; 

sumnat ( n , succnat ( m )  )  =  succnat ( sumna t ( n , m )) ; 
subnat ( n, zeronat () )  =  n; 
if  gtnat(n,m)  =  true() 
then 

subna t ( n , succna t ( m ) )  =  prednat ( subnat ( n, m ) ) 

else 

subnat ( n , succnat ( m ) )  is  undefined; 
end i f ; 

m 1 tna t C X , zerona t ( )  )  =  zeronatC); 
m 1 tnat ( X , succnat ( zeronat ()) )  =  x; 

mltnat(x,y)  =  sumnat ( x , m 1 tnat ( x , prednat ( y )))  ; 
if  eqnat (y, zeronat () )  =  trueC) 


divnat(x,y)  is  undefined; 
else  if  ltnat(x,y)  =  true() 
then 

divnat(x,y)  =  zeronat; 

e  1  se 

divnat(x,y)  =  suranat ( succnat ( zeronat ( ) 
divnat(subnat(x,y),y)) ; 

end i f  ; 
end i f  ; 

eqnat(n,m)  =  eqnat ( succnat ( n ), succnat ( m )) ; 

gtnat ( succnat ( n ), n )  =  true(); 

equi vre 1 ( eqnat, nat ) ; 

irreflexive(gtnat,nat) ; 

irreflexive( It nat,  nat) ; 

transitive( gtnat,  nat ) ; 

transitive( It nat,  nat) ; 

transitive(genat,nat) ; 

transitiveC lenat,nat) ; 

ant  i  syminetr  i  c  (  genat ,  nat )  ; 

ant i symmetr i c ( 1 enat , nat ) ; 

symmetric (nenat, nat) ; 

commutat i ve  <  sumnat ,  nat )  ; 

commutat i ve ( m 1 tnat ,  nat ) ; 

associativeC  sumnat,  nat) ; 

associativeCml tnat,  nat) ; 

end  natura 1 ; 


Resource  integer  is 

Extension  of 
boo  1 ean, 
natura I 

Operand  Types 
int ; 

Operators 

zeroint:  ->  int; 
ntoi :  nat  ->  int ; 
iton:  int  ->  nat; 
predint:  int  ->  int; 
succint:  int  ->  int; 
sumint:  int, int  ->  int; 
mltint:  int, int  ->  int; 
divint:  int, int  ->  int; 
modint:  int, int  ->  int; 
eqint:  int, int  ->  bool; 
gtint:  int, int  ->  bool; 


Derived  Operators 

Itint:  int, int  ->  bool; 

gelnt:  int, Int  ->  bool; 

leint:  int, int  ->  bool; 

neint:  int, int  ->  bool; 

Derived  Definition 

ltint(n,m)  =  not (or < gt int ( n, m ) , eq int ( n , m ) ) ) 
geint(n,in)  =  not(  1  tint(n,  m)  ; 
leint(n,ni)  =  not  ( gt  int  ( n,  m )  ; 
neint(n,m)  =  not ( eqint ( n, m ) ; 

Properties 

pred int ( succint ( n ) )  =  n; 
succint(predint(n) )  =  n; 
ntoi ( zeronat ( ) )  =  zerointC); 
ntoi ( succnat ( n ) )  = 

sumi nt ( succint (zeroint( ) ) , ntoi (n) ) ; 
i ton ( zero int () )  =  zeronatC); 
if  1 t int ( X , zeroint ( ) )  =  true() 
then 

iton(x)  is  undefined; 

e  1  se 

i  ton  (  succint  (  X  )  )  =  suninat( 

succnat ( zeronat ( ) , i ton( x ) ) ) ; 

end i f ; 

if  1 t int ( X , zeroint () )  =  true() 
then 

absint(x)  =  sub i nt (zero i nt (), x ) ; 

e  1  se 

abs i nt ( X )  =  x ; 
end i f  ; 

sumint ( n , zeroi nt ( ) )  =  n; 

sum i nt ( n, succ i nt ( m ) )  =  succint ( sumi nt ( n, m )) ; 
subint(n, zeroint () )  =  n; 

sub i nt < n, sued nt ( m ) )  =  predi nt ( subi nt ( n , m ) ) ; 

sub i nt ( n , succi nt < m ) )  is  undefined; 
m 1 t i nt ( X , zero i nt ( ) )  =  zeroint(); 
ra 1  tint ( x , succint ( zeroint ()) >  =  x; 
mltint(x,y)  =  sumi nt ( x , m 1 t int ( x , pred i nt ( y ))) ; 
if  eqint ( y , zero int C ) )  =  true() 
then 

divint(x,y)  is  undefined; 
else  if  I t i nt (abs i nt ( X ) , abs i nt ( y ) )  =  trueC) 
then 

divint(x,y)  =  zeroint; 
else  if  or ( 

and ( gtint( x, zeroint( ) ) , 
gtint(y,zeroint() )), 
and( ltint(x,zeroint( ) ), 
ltint(y,zeroint( ) ) ) 

)  =  true ( ) 


divint(x,y)  =  sum int ( succint ( zeroint ( ) , 
divint(subint(x,y),y) ) ; 

e  1  se 

divint(x,y)  =  sumint (predint (zeroint () , 
divint(sumint(x,y),y) ) ; 

end i f ; 
end i f  ; 
end  if; 

if  gt int (m , zero int () )  =  true() 
then 

if  1 t int ( n , zero int () )  =  true() 
then 

modint(n,m)  =  modint ( sumint ( n, m ), m ) 

else 

modint(n,m)  =  subnat(n, 

m I tnat (m,divint(n,m) ) ) ; 

end i f ; 

else 

modint(n,m)  is  undefined; 
end i f ; 

eqint(n,m)  =  eqint ( succint (n ), succi nt (m )) ; 

gt i nt ( succint ( n ), n )  =  true(); 

equi vre 1 (eqint, int) ; 

irreflexive(gtint, int) ; 

irref lexive( 1  tint, int) ; 

transitive(gtint, int)  ; 

transitive( Itint, int) ; 

transitive(geint, int); 

transitive( leint, int) ; 

anti symmetr ic(geint, int) ; 

anti symmetr ic( leint, int) ; 

symmetr ic(neint, int) ; 

commutat i ve ( sum int, int) ; 

commutat 1 ve(ml tint, int) ; 

associative( sum int, int) ; 

associative(mltint, int) ; 

end  integer; 


Resource  character  is 

Extension  of 
boo  1 ean 

Operands 
char ; 

Operators 

’ A’ , ’B’ , ’C’ , . . . , ’Z’ :  ->  char; 
’ a' ,’ b c z ’ ;  ->  char; 


f  .  f  1  9 

»  + ' 

9^9  9  9 

9  9  9 

9  '  9  9/9 

9^9 

’  C’  , 

-> 

char ; 

»  f  »  1  ft  1 

f  9 

9  1  9  9  9  * 

*  9  • 

9  •  9 

-> 

9  *  9  9  9  1 

9  9  9  9  9 

char ; 

9  9  9^9  1 

•  9  ^9 

979  1 

-> 

char  ; 

’3> 

9  A  9  9  C  9 

9  9  ^  9 

'6’ , ’7' , 

’8’  , 

'9’  , 

» 0’  ; 

-> 

char ; 

NUL;  ->  char; 
SOH:  ->  char; 
STX:  ->  char; 
EXT;  ->  char; 
EOT:  ->  char; 
ENQ;  ->  char; 
ACK;  ->  char; 
BEL:  ->  char; 
BS:  ->  char; 
HT :  ->  char; 
LF :  ->  char; 
VT :  ->  char; 
FF ;  ->  char; 
CR :  ->  char; 
SO:  ->  char; 
SI :  ->  char ; 
OLE;  ->  char; 
DCl;  ->  char; 
DC2;  ->  char; 
DCS:  ->  char; 
DC4 ;  ->  char; 
NAK ;  ->  char; 
SYN;  ->  char; 
ETB :  ->  char; 
CAN:  ->  char; 
EM:  ->  char; 
SUB:  ->  char; 
ESC:  ->  char; 
FS ;  ->  char ; 
GS :  - >  char ; 
RS:  ->  char; 
US;  ->  char; 
SP:  ->  char; 
DEL:  ->  char; 


eqchar:  char, char  ->  bool; 
gtchar:  char, char  ->  bool; 


Derived  Operators 

1 tchar :  char, char  ->  bool; 
gechar:  char, char  ->  bool; 
lechar:  char, char  ->  bool; 
nechar:  char, char  ->  bool; 

Derived  Definition 

ltchar(n,m)  =  not ( or ( gtchar ( n, m ), eqchar ( n , m )) ) 
gechar(n,m)  =  not ( 1 tchar ( n, m )) ; 
lechar(n,m)  =  not ( gtchar ( n , m )) ; 


nechar(n,m)  =  not(eqchar( 


Properties 

gtchar (DLE, ’ )  =  true(); 
gtchar  )  =  true(); 

gtchar 1 ’ )  =  true(); 
gtchar (’!*,'{’ )  =  true(); 
gtchar 2 ’ )  =  true(); 

gtchar('2’,...’a’)  =  true(); 
gtchar (’ a’ )  =  true(); 
gtchar )  =  true(); 
gtchar ^ )  =  true(); 
gtchar ^ )  =  true(); 
gtchar )  =  true(); 
gtchar C * )  =  true(); 
gtchar  Z’ )  =  trueO; 

gtchar  (’ Z’ A’  )  =  trueO; 

gtchar (’ A* )  =  true(); 

gtchar (’ 0’ )  =  true(); 

gtchar (*?’,’>’ )  =  true(); 

gtchar )  =  true(); 

gtchar )  =  trueC); 

gtchar )  =  true(); 

gtchar )  =  true(); 

gtchar 9' )  =  true(); 

gtchar (’ 9’ 0’ )  =  true(); 
gtchar  (’ 0 )  =  trueO; 

gtchar )  =  true(); 

gtchar )  =  true(); 

gtchar )  =  trueC); 

gtchar )  =  true(); 

gtchar )  =  true(); 

gtchar )  =  true(); 

gtchar )  =  true(); 

gtchar )  =  true(); 

gtchar  (’’ )  =  true(); 

gtchar  =  true(); 

gtchar (’ X’ ,*$’ )  =  true(); 

gtchar =  true( ) ; 
gtchar  (’  #’  ,  ’  )  =  trueO  ; 

gtchar )  =  true(); 
gtchar SP )  =  true(); 
gtchar (SP, US)  =  true(); 
gtchar ( US, RS )  =  true(); 
g tchar ( RS , GS )  =  true(); 
gtchar ( GS , FS )  =  true(); 
gtchar ( FS , ESC)  =  true(); 
gtchar (ESC, SUB)  =  true(); 
gtchar ( SUB , EM )  =  true(); 
gtcha r ( EM , CAN )  =  true<); 
gtchar (CAN, ETB )  =  true(); 


gtchar(ETB,  SYN)  =  trueO; 
gtchar(SYN,NAK)  =  trueO; 
gtchar (NAK, DC4)  =  true(); 
gtchar(DC4,DC3)  =  trueO; 
gtchar  (DC3,  DC2)  =  trueO; 
gtchar < DC2, DCl )  =  true(); 
gtchar(DCl,DLE)  =  trueO; 
gtchar ( DLE, S I )  =  true(); 
gtchar ( S I , SO )  =  true(); 
gtchar (SO, CR)  =  true(); 
gtchar (CR, FF)  =  true<); 
gtchar (FF, VT)  =  true<); 
gtchar ( VT, LF)  =  trueC); 
gtchar(LF,HT)  =  trueO; 
gtchar ( HT, BS )  =  trueC); 
gtchar (BS, BEL)  =  true(); 
gtchar ( BEL, ACK )  =  true<); 
gtchar (ACK, ENQ)  =  true(); 
gtchar (ENQ, EOT)  =  true(); 
gtchar  (EOT,  ETX)  =  trueO; 
gtchar  (ETX,  STX)  =  trueO; 
gtchar (STX, SOH)  =  true(); 
gtchar(SOH,NUL)  =  trueO; 
equl vre 1 (eqchar,char) ; 
irreflexive(gtchar,char) ; 
transitive(gtchar,char) ; 
irreflexive( ltchar,char) ; 
transitive ( 1 tchar ,  char ) ; 
transitive(gechar,char) ; 
transltive( 1 echar ) char )  ; 
ant i symmetr ic(gechar,char) 
ant i symraetr ic ( 1 echar , char ) 
symmetr I c ( nechar ) ; 

end  ; 


Resource  str ing (e 1 e 1 ment )  is 

Parameter  element  is 

Extension  of 
boo  1 ean 

Operands 
1  m : 

Operators 

eq 1 m :  1 m ,  1 m  - >  boo  1 ; 

gtlm:  lm,lm  ->  boo  1 ; 


Derived  Operators 


Itlm:  lm,lin  ->  boo  1  ; 
ge Im:  1 m,  1 m  ->  boo  1 ; 
lelm:  lm,lin  ->  boo  I  ; 
nelm:  lm,lin  ->  bool; 

Dvrivad  Definition 

ltlnj(n,m)  =  not  ( or  (  gt  1  m  ( n,  m ) ,  eq  1  m  ( n,  m )  )  ) 
gelm(n,m)  =  not ( 1 t 1 m ( n, m ) ) ; 
lelm(n,in)  =  not  (  gt  1  m  ( n,  m )  )  ; 
nelm(n,(n)  =  not  ( eq  1  m  ( n ,  m  )  )  ; 

Properties 

equivrel (eqlm, Im) ; 
irreflexiveCgtlm, Im); 
transitive(gtlm, Im); 
irreflexiveC Itim, Im) ; 
transitiveCltlm, Im); 
transitiveCgelm, Im); 
transitive( lelm) Im) ; 
anti symmetr ic(gelm, Im); 
anti symmetr ic(lelm,lm); 
symmetr i c ( ne 1 m )  ; 

Extension  of 
natura 1 ; 
boo  1 ean ; 

Operands 

str . 1 m ; 

Operators 

nullstr.lm:  ->  str.lm; 
makestr.lm:  Im  ->  str.lm; 
lenstr.lm:  str.lm  ->  nat; 
headstr.lm:  str.lm  ->  Im; 
tailstr.lm;  str.lm  ->  str.lm; 
catstr.lm:  s tr . 1 m , s tr . 1 m  ->  str.lm; 
eqstr.lm:  str . 1 m, str . 1 m  ->  bool; 
gtstr.lm:  s t r . 1 m , s t r . 1 m  ->  bool; 


Derived  Operators 

1 tstr . 1 m : 

str . 1 m, str . 1 m 

-> 

bool; 

gestr . 1 m : 

str. Im,str. Im 

-> 

boo  1  ; 

1 estr . 1 m : 

str. Im.str. Im 

-> 

boo  1  ; 

nestr . 1 m : 

str. 1 m, str . Im 

-> 

boo  1  ; 

Derived  Definition 
ltstr.lm(n,m)  = 


not(or(gtstr.  lm(n,m),eqstr.  lm(n,m))); 
ges tr . 1 m ( n, m )  =  not ( 1 tstr . 1 m ( n , m ) ) ; 

1 es tr .  1 m ( n , m )  =  not ( g ts t r  .  1 m ( n, m ) ) ; 
nes tr . I m ( n, m )  =  not ( eqs tr . I m ( n , m ) ) ; 


Properties 


I  enstr .  1  m  ( nu  1  1  sir .  1  in  < )  )  =  zeronat(); 

1 enstr . 1 m ( makestr . 1 m ( 1 ) )  =  succnat ( zeronat ( ) ) 
lenstr.  lm(catstr.  ImCsl, s2) )  = 

sumnat (  lenstr.  Im(sl),  lenstr.  Iin(s2)  )  ; 
headstr . ImCmakestr . lm( 1 ) )  =  1; 
tai 1 str . 1 m (makestr . 1 m ( 1 ) )  =  nu 1 1 str . 1 m ( ) ; 
heads tr .  1 m ( catstr . 1 m (makes tr .  1 m ( 1 ), s  )  )  =  1; 
tai 1 str . 1 m ( catstr . 1 m (makestr . 1 m ( 1 ), s ) }  =  s; 
headstr. lm(nul 1 str. lm( ) )  is  undefined; 
tai 1 str . 1 m (nu 1 1 s tr . 1 m ( } )  =  nul 1 str. lm( ) ; 
cats tr . 1 m ( catstr . 1 m ( si , s2) , s3 )  = 

catstr. lm(sl,catstr. Im(s2,s3)} ; 
catstr . 1 m (nu 1 1 str . 1 m ( ) , s )  =  catstr. lm( 
s,nullstr.lm())  =  s; 

implies(eqlm(ll, 12), eqs tr . lm( makestr. Im(ll), 
makestr . 1 m( 1 2) ) )  =  true(); 
implies(gtlm(ll, 12),gtstr. lm( makestr. Im(ll), 
makestr . 1 m ( 1 2) ) )  =  true(); 
gtnat( lenstr. lm( makestr. lm( 1 ) , 

1 enstr . 1 m ( nu 1 1 str . 1 m () )  =  true(); 
implies(gtnat(lenstr.lm(sl), lenstr. Im(s2)}, 
gtstr . 1 m ( si , s2 )  =  true(); 
if  1 enstr . 1 m ( si )  !=  zeronat() 

then 

gtnat( lenstr. lm( catstr. Im(sl,s2), 
lenstr. Im(s2)  =  true(); 

e  1  se 

eqnat (lenstr.  lm( catstr.  Ira(sl,s2), 

1  enstr . 1 m ( s2 )  =  true(); 
endif  ; 

equivrel (eqstr. Im, str. Im) ; 
lrreflexive(gtstr. lm,str.  Im); 
transitive(gtstr. lm,str. Ira); 
irreflexive( Itstr. lm,str. Im) ; 
transitive(ltstr. lm,str. Im); 
transitive(gestr. lm,str. Im); 
transitive( lestr. lm)str. Im) ; 
ant i symmetr ic(gestr. lm,str. Im) ; 
ant i symme tr lc( lestr. Ira, str.  Im)  ; 
symmetr ic(nestr. lm,str. Im); 

end  str ing (e 1 ement )  ; 


Resource  str i ng ( character )  is 

where 

1 ra  =  char ; 

nullstr.char  =  nullstr.lm; 
makestr. char  =  makestr. Im; 
len.char  =  lenstr. Im; 


head . char 
tail. char 
cat. char 
eq.char  = 
gt.char  = 
It. char  = 
ge.char  = 
le.char  = 
ne.char  = 


=  headstr . Im; 
=  tai  1  str  .  1  in ; 
:  catstr . 1 m ; 
eqs tr . 1 m ; 
gtstr . Im; 

1 tstr .  1 m  j 
gestr . 1 m ; 

1  estr .  1 m ; 
nestr . 1 m ; 


end  str ing (character ) : 


Resource  identifiers  is 

Extension  of 
boo  1 ean 


Operands 
memi d ; 
regid  ; 
stk id ; 
fid; 


Operators 

idopers (memi d , memsem ) ; 
idopers(redid, regseg)  ; 
idopers(stkid,stkseg}  ; 
idopers(fid. fseg) ; 

Properties 

idaxiom(memid,memseg) ; 
i da xiom (regid, regseg) ; 
idaxiom(stkid, stkseg) ; 
idaxiom(fid, fseg) ; 


Resource  memaddress  is 

Extension  of 

i dent i f ier s , 
boo  1 ean 

Operands 

memaddr ; 

Operators 

star tmemaddr :  memid  ->  memaddr; 
nextmemaddr:  memaddr  ->  memaddr; 
prevmemaddr:  memaddr  ->  memaddr; 


getmemid:  tnemaddr  ->  memld; 
offset:  int, memaddr  ->  memaddr; 
eqmemaddr:  memaddr , memaddr  ->  bool; 

Properties 

I  prevmemaddr ( star tmemaddr ( i > )  is  undefined; 

I  prevmemaddr (nextmemaddr (m) )  =  m; 

I  nextmemaddr ( prevmemaddr (m) )  =  m; 

I  of f set ( succint ( n ) , m)  =  nex tmemaddr ( of f set ( n, m )) ; 

if  offset(n,m)  =  startmemaddr ( > 
then 

.  of f set ( predint ( n ), m)  is  undefined; 

'  else 

I  of f set ( pred int (n) , m)  =  prevmemaddr (of fset(n, m) ) 

'  endif; 

I  eqmemid ( i , getmemi d ( of f set < n, star tmemaddr ( i )}) )  = 

true ( ) ; 

eqmemaddr ( startmemaddr ( i 1 ), startmemaddr ( i2} )  = 
i  eqmemid ( i 1 , i2) ; 

I  eqmemaddr ( startmemaddr ( i ), nex tmemaddr ( a ) )  =  false() 

'  eqmemaddr (nextmemaddr (al) , nextmemaddr (a2) )  = 

I  eqmemaddr (al , a2) ; 

of f set ( zeroint ( ) , m )  =  m; 
eqivrel ( eqmemaddr , memaddr ) ; 

end  memaddress  ; 

I 

Resource  regaddress  is 

Extension  of 

identl f iers, 

I  boolean 

Operands 

regaddr ; 

Operators 

star tregaddr :  regid  ->  regaddr; 
nextregaddr:  regaddr  ->  regaddr; 
prevregaddr:  regaddr  ->  regaddr; 
getregid:  regaddr  ->  regid; 
eqregaddr:  regaddr , regaddr  ->  bool; 

Properties 

prevregaddr ( star tregaddr ( i ) )  is  undefined; 
prevregaddr ( nex tregaddr (m ) )  =  m; 
nextregaddr ( prevregaddr (m) )  =  m; 

eqregaddr (startregaddr( 11 ) , startregaddr( i2) )  = 
eqreg i d ( i 1 , i 2 ) ; 

eqregaddr(startregaddr(i),nextregaddr(a) )  = 


f  a  1  se  (  ) 


eqregaddr(nextregaddr{al),nextregaddr(a2) )  = 

eqregaddr (al , a2) ; 

eqivrel (eqregaddr, regaddr)  ; 

end  regaddress; 


Resource  stkaddress  is 

Extension  of 

identif iers, 
boo  1 ean 

Operands 

stkaddr ; 

Operators 

getstkid:  stkaddr  ->  stkid; 
eqstkaddr:  stkaddr , atkaddr  ->  bool; 

Properties 

eqstkaddr (nextstkaddr(al) ,nextstkaddr(a2) )  = 
eqstkaddr (al , a2) ; 
equlvrel (eqstkaddr, stkaddr) ; 

end  stkaddress  ; 


Resource  files  is 

Extension  of 

identif iers, 
boo  1 ean 

Operands 

file; 

Operators 

getflle;  fid  ->  file; 
eqflle:  file, file  ->  bool; 

Properties 

eqf i 1 e < getf i 1 e ( i 1 ) , get f i 1 e ( i 2) )  =  eqf i 1 e ( i 1 , i 2 ) 
equivrel (eqfi le, fi le) ; 

end  files; 

Resource  operator c 1  asses  is 
Extension  of 
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Operands 
mop : 
dop; 
top; 
qop; 
sop; 
oop; 
rop; 
bop; 

Operators 

Properties 
end  operator c 1  asses ; 
Resource  instructiontype  is 

Extension  of 

Operands 

Instr ; 

Operators 


Properties 
end  i ntruct i ontype ; 
Resource  typing  is 


Extension  of 
boo  1 ean ; 
natural ; 
integer ; 
character ; 
str ing ( character )  ; 
i dent i f i er s ; 
memaddress ; 
regaddress ; 
stkaddr ; 
flies; 

operatorc lasses; 
intructiontype; 


Operands 
type ; 


va  1  ; 


Operators 

typi ngopers ( boo  1  ) 
typingopers(nat)  ; 
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typingopers<int) j 
typingopers (char )  ; 
typingopers(str-char) ) ; 
typingopers (memi d )  ; 
typingopers ( reg i d )  ; 
typingopers ( stk i d )  ; 
typingopers(fid) ; 
typingopers (memaddr ) ; 
typingopers ( regaddr ) ; 
typingopers (stkaddr)  ; 
typingopers(file)  ; 
typingopers (mop) ; 
typingopers (dop) ; 
typingopers ( top) ; 
typi ngoper s ( qop ) ; 
typingopers (sop) ; 
typingopers (oop) ; 
typingopers ( rop) ; 
typingopers (bop) ; 
typingopers ( i nstr  )  ; 

whattype:  va 1  ->  type; 
eqtype:  type, type  ->  bool 

Properties 

typingaxiom(bool ) ; 
typi ngax iom ( nat )  ; 
typingax i om ( int ) ; 
typingax i om ( char ) ; 
typingaxiom(str.char)  ; 
typingax i om ( memi d )  ; 
typingaxiom(regid)  ; 
typingaxiom(stkid)  ; 
typingaxiom(fid)  ; 
typingaxiom( memaddr )  ; 
typingaxiom( regaddr )  ; 
typingax iom( stkaddr)  ; 
typingaxiom(fi le) ; 
typ i ngax i ora ( mop ) ; 
typingaxiom(dop) ; 
typingax iom ( top)  ; 
typ i ngax i om ( qop ) ; 
typingaxiom(sop) ; 
typi ngax i om ( oop ) ; 
typingax i om ( rop )  ; 
typi ngax i om ( bop )  ; 
typingaxiom( instr)  ; 
equ ivrel  ( instr)  ; 


end  typing; 
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Resource  operators  is 

Extension  of 

operatorclasses, 

typing 

Operands 

Operators 

boolnot:  ->  mop; 
booland:  ->  dop; 
boolor:  ->  dop; 
natpred;  ->  mop; 
natsucc;  ->  mop; 
natsura:  ->  dop; 
natsub:  ->  dop; 
nateq:  ->  rop; 
natgt:  ->  rop; 
natlt:  ->  rop; 
intpred:  ->  mop; 
intsucc:  ->  mop; 
intabs:  ->  mop; 
intntoi :  ->  mop; 
intiton:  ->  mop; 
intsum:  ->  dop; 
intsub:  ->  dop; 
Intmlt:  ->  dop; 
intdiv:  ->  dop; 
intmod:  ->  dop; 
inteq:  ->  rop; 

Intgt:  ->  rop; 
int 1 t :  ->  rop ; 
chareq:  ->  rop; 
chargt:  ->  rop; 
charmakestr:  ->  mop; 
charstrien:  ->  mop; 
charheadstr:  ->  mop; 
chartailstr:  ->  mop; 
charcatstr:  ->  dop; 
str. chareq:  ->  rop; 
str. chargt:  ->  rop; 
i  sboo I :  - >  bop ; 
isnat:  ->  bop; 
isint:  ->  bop; 

1  schar :  ->  bop ; 
isstr.char:  ->  bop; 
i smem id;  - >  bop ; 
isregid;  ->  bop; 
isstkid:  ->  bop; 
isfid:  ->  bop; 
ismemaddr:  ->  bop; 
isregaddr:  ->  bop; 
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isstkaddr:  ->  bop; 

Isflle:  ->  bop; 
ismop:  ->  bop; 

Isdop:  ->  bop; 
istop:  ->  bop; 
isqop:  ->  bop; 
issop:  ->  bop; 
isoop:  ->  bop; 
isrop:  ->  bop; 
isbop:  ->  bop; 

Isinstr:  ->  bop; 

applymop:  mop,val  ->  val; 
applydop:  dop,val,val  ->  val; 
applytop:  top, va 1 , val , val  ->  val; 
applyqop:  qop, va 1 , va 1 , va 1 , va 1  ->  val; 
applysop:  sop, va 1 , val , val , va 1 , va 1  ->  val; 
applyoop:  oop, va 1 , va 1 , va 1 , va 1 , va 1 , va 1  ->  val; 
applyrop:  rop,val,val  ->  val; 
applybop:  bop, val  ->  val; 


Properties 

appl ymop ( boo  1  not ( ) , V )  =  va 1  of boo  1 ( not ( atomof boo  1 ( v ) ) 
appl ydop ( boo  1  and ( ) , vi , v2)  =  valofbooH 
and (atomof boo  1 (vl),atomofbool (v2) ) ; 
app 1 ydop(boo 1  or ( ) , vl , v2)  =  valofboolC 
or(atomofbool (vl),atomofbool (v2) > ; 
applyniop(natpred( ) ,  v)  =  valofnatC 
prednatCatomofnatCv)) ; 
applymop(natsucc( ) , v)  =  valofnatC 
succnat (atomof nat ( v ) ) ; 
app 1 ydop( natsum ( } , vl , v2 >  =  valofnatC 

sumnat ( atomof nat ( vl ), atomof nat(v2) ) ; 
app 1 ydop ( natsub (), vl , v2)  =  valofnatC 

subnat (atomof nat ( vl ),atomofnat(v2) ) ; 
applymopC intpredC ) , v)  =  valofintC 
predintCatomofintCv) ) ; 
applymopC intsuccC ), v)  =  valofintC 
succintCatomofintCv) ) ; 
app 1 ymop ( intabs (), V )  =  valofintC 
abs i nt (atomof i nt  C  v ) ) ; 
applymopC intntoi C ), v)  =  valofintC 
ntoi int (atomof int (v) ) ; 
app 1 ymop ( i nt i ton C ), V )  =  valofintC 
itonintCatomofintCv)  )  ; 
app 1 ydop C 1 nt sum C ), V 1 , v2 )  =  valofintC 

sumint(atomofint(vl),atomofint(v2) ) ; 
appl ydopC intsubC ) , vl , v2)  =  valofintC 

subint(atomofint(vl),atomofint(v2) ) ; 
applydopCintml tC ) , vl, v2)  =  valofintC 

m 1 t int (atomof int(vl),atomofint(v2) ) ; 


appiydop< intdlv( ) , vl, v2)  =  valoflnK 

di Vint (atomof int  <  vl ) , atomof int ( v2) ) ; 
applydopC  intn)od( ) ,  vl ,  v2)  =  valofinK 

mod int ( atomof int (vl) , atomof int ( v2) ) ; 
app 1 ymop ( charstr I en ( ) , v)  =  valofnatC 
1 enstr . char (atomof str . char ( v ) ) >  ; 
app I ymop(charmakestr ( ) , v)  =  va 1  of str . char ( 
makes tr . char (atomof char ( v ) ) ) ; 
applymop(charheadstr ( ) t v)  =  valofchar( 
headstr . char ( atomof str . char ( v )  )  )  ; 
appl ymop ( char tai 1 str (), V )  =  val of str . char ( 
tai 1 str . char (atomof str . char ( v ) ) ) ; 
appIydop(charcatstr ( ) , vl, v2)  =  va 1  of str . char ( 
catstr .  char (atomof str . char ( vl > , 
atomof str . char ( v2) ) ) ; 
relop(nat, eq) ; 
re  1  op (nat , gt ) ; 
rel op(nat, 1 t) j 
re  1  op ( i nt , eq) ; 
relop( int, gt)  ; 
relop( int, It); 
relop(char, eq) ; 
relop(char, gt) ; 
relop(str.char,eq) ; 
rel op (str. char, gt)  ; 
isops (boo  1 ) ; 
isops (nat ) ; 
i sops ( int ) ; 
isops (char )  ; 
isops ( str . char ) ; 
isops (memid)  ; 
isops (regid) ; 
isops ( stk i d )  ; 
i sops (fid)  ; 
isops ( memaddr  )  ; 
i sops ( regaddr )  ; 
isops ( stkaddr  )  ; 
i sops (file); 
isops (mop) ; 
i sops ( dop) ; 
isops ( top) ; 
isops(qop) ; 
isops ( sop ) ; 
i sops ( oop ) ; 
isops (rop) ; 
i sops ( bop )  ; 
isops ( instr )  ; 


end  operators; 


R«sourc«  Intructions  is 


Extension  of 
nature  1 , 
integer , 
memaddress , 
regaddress , 
stkaddress , 
operatorc 1  asses , 
intructiontype, 
typing 

Operands 

Operators 

org;  ->  instr; 
extern:  ->  instr; 
g I ob 1 :  ->  instr ; 
mbegin:  ->  instr; 
mend:  ->  instr; 
offst:  int,regaddr  ->  instr; 
link:  regaddr,nat  ->  instr; 
unlink:  regaddr  ->  instr; 
monads:  mop, regaddr  ->  instr; 
monad:  mop, regaddr , regaddr  ->  instr; 
monadi:  mop, va 1 , regaddr  ->  instr; 
dyads:  dop, regaddr , regaddr  ->  instr; 
dyadsi:  dop, va 1 , regaddr  ->  instr; 
dyad:  dop, regaddr , regaddr , regaddr  ->  instr; 
dyadi:  dop, va 1 , regaddr , regaddr  ->  instr; 
triads:  top, regaddr , regaddr , regaddr  ->  instr; 
triadsi:  top, va 1 , regaddr , regaddr  ->  instr; 
triad:  top, regaddr , regaddr , regaddr , regaddr  ->  instr; 
triadi:  top, val , regaddr , regaddr, regaddr  ->  instr; 
quads:  qop, regaddr , regaddr , regaddr , regaddr  ->  instr; 
quad:  qop, regaddr, regaddr, regaddr, 
regaddr , regaddr  ->  instr; 
sex ads:  sop, regaddr, regaddr, regaddr, 
regaddr , regaddr , regaddr  ->  instr; 
sexad:  sop, regaddr, regaddr, regaddr, regaddr, 
regaddr , regaddr , regaddr  ->  instr; 
octads:  oop, regaddr, regaddr , regaddr, regaddr, 
regaddr , regaddr , regaddr , regaddr  ->  instr; 
octad :  oop, regaddr, regaddr, regaddr, regaddr, 

regaddr , regaddr , regaddr , regaddr , regaddr  ->  instr; 
movi_m:  val,memaddr  ->  instr; 
movi_pcr:  val,int  ->  instr; 
movi_r:  val, regaddr  ->  instr; 
movi_ri:  val, regaddr  ->  instr; 
movi_rid:  va 1 , regaddr , int  ->  instr; 
movi_ridn:  va 1 , regaddr , nat , i nt  ->  instr; 
mov_m_m:  memaddr , memaddr  ->  instr; 
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wnw  VI  ^ 


mov_in_^r ;  memaddr,  regaddr  ->  instr; 
tnov_m_ri:  memaddr ,  regaddr  ->  instr; 
mov_m_rid:  memaddr, regaddr, int  ->  instr; 
mov_m_ridn;  memaddr , regaddr , nat, int  ->  instr; 
mov_pcr_pcr :  int, int  ->  instr; 
mov_pcr_r;  int, regaddr  ->  instr; 
mov_pcr_ri:  int, regaddr  ->  instr; 
mov_jpcr_rid:  int,  regaddr ,  int  ->  instr; 
mov_pcr_r i dn :  int, regaddr , nat, int  ->  instr; 
mov_r_m:  regaddr , memaddr  ->  instr; 
mov_r_pcr:  regaddr, int  ->  instr; 
mov_r_r ;  regaddr , regaddr  ->  instr; 
mov_r^ri:  regaddr , regaddr  ->  instr; 
mov_r_rid:  regaddr , regaddr, int  ->  instr; 
mov_r__ridn;  regaddr,  regaddr ,  nat,  int  ->  instr; 
mov_ri_m:  regaddr , memaddr  ->  instr; 
mov_ri_pcr:  regaddr, int  ->  instr; 
mov_ri_r:  regaddr , regaddr  ->  instr; 
mov_ri_ri:  regaddr , regaddr  ->  instr; 
mov_ri_rid:  regaddr , regaddr , int  ->  instr; 
mov_ri_ridn:  regaddr , regaddr , nat, int  ->  instr; 
mov_rid_m:  regaddr , int, memaddr  ->  instr; 
mov_rid_pcr:  regaddr, int, int  ->  instr; 
mov_rid_r:  regaddr , int, regaddr  ->  instr; 
mov_rid_ri!  regaddr , int , regaddr  ->  instr; 
mov_rid_rid;  regaddr , int, regaddr , int  ->  instr; 
mov_rid_ridn;  regaddr , int, regaddr , nat , int  ->  instr; 
mov_rldn_ra;  regaddr , nat, int, memaddr  ->  instr; 
raov_r idn_pcr ;  regaddr , nat, int, int  ->  instr; 
mov_ridn_r:  regaddr , nat, int, regaddr  ->  instr; 
mov_ridn_ri!  regaddr, nat, int, regaddr  ->  instr; 
mov_r idn_r id !  regaddr , nat , int , regaddr , i nt  ->  instr; 
mov_r i dn_r i dn :  regaddr , nat, int, regaddr, nat, 
int  ->  instr; 

push_i ;  va],stkaddr  ->  instr; 

push_m;  memaddr , stkaddr  ->  instr; 

push_pcr;  int, stkaddr  ->  Instr; 

push_r :  regaddr , stkaddr  ->  instr; 

push_ri:  regaddr , stkaddr  ->  instr; 

push_rid:  regaddr , int, stkaddr  ->  instr; 

push_ridn:  regaddr, nat, int, stkaddr  ->  instr; 

pop_x :  stkaddr  ->  instr; 

pop_m;  stkaddr , memaddr  ->  Instr; 

pop_pcr :  stkaddr, int  ->  instr; 

pop_r ;  stkaddr , regaddr  ->  instr; 

pop_ri:  stkaddr , regaddr  ->  instr; 

pop_rid:  stkaddr , regaddr , int  ->  instr; 

pop_ridn:  stkaddr , regaddr , nat , 1 nt  ->  instr; 

nop:  ->  instr; 

stop:  ->  instr; 

jmp:  memaddr  ->  instr; 

jmp_i :  memaddr  ->  instr; 
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jmp_r:  regaddr  ->  instr; 
bra;  Int  ->  instr; 
bra_r;  regaddr  ->  instr; 

if:  re  1  op, regaddr , regaddr , memaddr  ->  instr; 

ifi:  relop, regaddr, val ,memaddr  ->  instr; 

ifte:  re  1  op, regaddr , regaddr , memaddr , memaddr  ->  instr; 

iftei:  re  1  op, regaddr , va 1 , memaddr , memaddr  ->  instr; 

if_pcr;  re  1  op, regaddr , regaddr , int  ->  instr; 

ifi_pcr;  re  1  op, regaddr , va 1 , int  ->  instr; 

ifte_pcr:  re  1  op, regaddr , regaddr , int, int  ->  instr; 

iftei_pcr;  relop, regaddr, val , int, int  ->  instr; 

test:  bop, regaddr , memaddr  ->  instr; 

testm:  bop, memaddr , memaddr  ->  instr; 

teste:  bop, regaddr , memaddr , memaddr  ->  instr; 

testme:  bop, memaddr , memaddr, memaddr  ->  instr; 

test__pcr:  bop,  regaddr ,  int  ->  instr; 

testm_pcr;  bop, memaddr , int  ->  instr; 

teste_pcr:  bop, regaddr , int, int  ->  instr; 

testme_pcr:  bop, memaddr , int, int  ->  instr; 

jsr:  memaddr , stkaddr  ->  instr; 

jsr_i;  memaddr , stkaddr  ->  instr; 

jsr_r:  regaddr , stkaddr  ->  instr; 

bsr;  int, stkaddr  ->  instr; 

bsr-r:  regaddr , stkaddr  ->  instr; 

rts:  stkaddr  ->  instr; 

open:  stkaddr  ->  instr; 

close:  stkaddr  ->  instr; 

read:  stkaddr  ->  instr; 

write:  stkaddr  ->  instr; 

Properties 
end  intructions; 


Resource  amstate  is 

Extension  of 
boo  1 ean, 
natura 1 , 
integer , 
str (character ) , 
memaddress , 
regaddress , 
f i I es , 

i dent i f ier s , 
typing 

Operands 
state ; 


Operators 


fetchm:  memaddr , state  ->  val; 
fetchr:  regaddr , state  ->  val; 
storem:  va 1 , memaddr , state  ->  state; 
storer:  va 1 , regaddr , state  ->  state; 

Initam:  ->  state; 
initstk:  stkaddr , state  ->  state; 
topstk:  stkaddr , state  ->  val; 
pushstk:  va 1 , stkaddr , state  ->  state; 
popstk:  stkaddr , state  ->  state; 
lalloc:  na.t, state  memld; 

Ifree:  memld, state  ->  state; 

indir:  nat, memaddr  ->  memaddr; 

infile:  file, state  ->  val; 

outfile:  va 1 , f i 1 e , state  ->  state; 

openflle:  str . char , f 1 1 e, int, int , state  ->  state 

closeflle:  file, state  ->  state; 

rmode:  ->  int; 

wmode :  ->  int: 

rwmode:  ->  int: 

openerr:  ->  int; 

openok:  ->  int; 

valdata:  ->  int; 

chardata:  ->  int; 

active:  memld, state  ->  bool; 

Properties 

topstk ( s , i ni tstk ( s ) )  is  undefined; 

popstk(s, initstk(s) )  is  undefined; 

popstk ( s , i ni tarn () )  is  undefined; 

stateaxiom(m, memaddr)  ; 

stateaxiomCr, regaddr)  ; 

tops tk ( s ( pushstk ( V , s , q ) )  =  v; 

popstk ( s (pushstk ( V , s , q) )  =  q; 

acti ve(m, ini tam( ) )  =  false(); 

act i ve ( 1  a  1 1 oc ( n, q ) q )  =  true(); 

act i ce ( m , 1 f ree ( m, q ) )  =  falseC); 

act i ve ( m , s tor er ( V , r , q ) )  =  active(m,q); 

act! ve(m, storem( V, a, q) )  =  active(m,q); 

act i ve ( m, 1 n 1 tstk ( s , q ) )  =  active(m,q>; 

act i ve ( m, pushs tk ( V , s , q )  =  active(m,q); 

act i ve ( m, pops tk ( s , q )  =  active(m,q); 

act  1 ve ( m, out f i 1 e ( V , f , q )  =  actlve(m,q); 

act i ve ( m, openf i 1 e ( s , f , X , y , q )  =  active(m,q); 

act  1 ve ( m, c 1 osef i I e ( f , q )  -  actlve(m,q); 

if  active(m,q)  =  falseC) 

then 

f e tchm ( of f se t ( n , m ) , q )  is  undefined; 
end  i  f  ; 

if  active(m,q)  =  false(); 
then 

storem ( V , of f set ( n, m ), q )  Is  undefined; 


^ 


’^Vi.v.v'.^’v'.'w 


endi f  ; 

If  1 tint<n, ntoi (n2) )  =  true() 
then 

offset(n,offset(nl, star tmemaddr ( 
lalloc(n2,q))))  = 
offset(suinint(n,nl), 
star tmemaddr ( lal loc(n2, q) ) ) ; 

e  1  se 

offset (n, offset (ni, star tmemaddr ( 

1  a  1 1 oc ( n2, q ) ) ) )  is  undefined; 

end i f ; 

ind i r ( zeronat ( ) , m )  =  m; 

if  whattype ( f etchm ( ind i r ( n, m ) , q )  =  typememaddr ( ) 
then 

indi r ( succnat ( n } , m )  * 

atomof memaddr ( fetchm(indir(n»m) ,q) ) ; 

e  1  se 

i nd i r ( succnat ( n ) , m )  is  undefined; 
end i f ; 

openf i 1 e ( s , f , n, openf i 1 e ( s , f , m, X , q ) )  is  undefined; 
c 1 osef i 1 e ( f ( openf i 1 e ( s» f , n» X , q ) )  =  q; 
inf i 1 e ( f , i ni tarn () )  is  undefined; 
inf i 1 e ( f , c 1 ose ( f , q ) )  is  undefined; 
inf i 1 e ( f , openf i 1 e ( s , f , wmode ( } , X , q ) )  is  undefined; 
outf i 1 e ( V , f , i ni tarn ( ) )  is  undefined; 
outf i I e ( V, f , c ! ose ( f , q) )  is  undefined; 
outf i 1 e ( V, f , openf i 1 e ( s , f , rmode ( ) , X , q ) )  is  undefined; 
out i f 1 e < V, f , openf i 1 e ( s , f , m, char data ( ) ,  q) ) 
is  undefined; 


end  amstate; 


Resource  am  is 

Extension  of 

memaddress , 
intructiontype, 
typing, 
amstate 

Operands 

prog:  memaddr , s tate  ->  state; 

cond :  va 1 , memaddr , memaddr  -  memaddr; 
exq:  i ns tr , memadd r , s tate  ->  state; 

Operators 

prog(m,q)  =  e xq ( a t omof i ns t r ( f e t chm ( m , q ) ) , m , q ) ; 
cond ( va 1  of boo  1 ( true ( ) , ml , m2 ) )  =  ml; 
cond ( va 1  of  bo  1  1  ( f a  1 se ( ) , ml , m2) )  =  m2; 
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Properties 

exqCof f st ( i , r ) , m, q)  = 

prog(nextmemaddr (m) , 
storer ( 

va I  of memaddr (offsetC 

i . a tomof memaddr (fetchr(r,q) ) )  ), 

r, q) )  ; 

exq ( 1  ink ( r , n ) m, q )  = 

prog ( nextmemaddr (m) , 
storer ( 

va 1  of memaddr ( star tmemaddr (lalloc(n,q))) 
r,storem<fetchr(r,q), 

star tmemaddr (lalloc(n,q),q}})); 
exq<un 1  ink ( r ) , m, q )  = 

prog (nextmemaddr (m) , 

1  f  ree  ( 

getmemi d (atomof memaddr (fetch(r,q))), 
storer ( 

f etchm (atomofmemaddr(fetchr(r,q)  ,q) 
r , q) ) > ; 

exq(monads <o, rl ) , m, q)  = 
prog (nextmemaddr (m) , 

storer(appI ymop( o, fetchr(rl,q) ), 
rl ,  q)  )  ; 

exq ( monad ( o , r 1 , r2) , m, q )  = 
prog ( nex tmemaddr (m), 

storer (applymop(o, fetchr(rl,q) ), 
r2, q) ) ; 

exq(monadi (o, V, rl ) , m, q)  = 
prog (nextmemaddr (m), 

storer(appI ymop( o, v ) )  ,  r 1 ,  q ) )  ; 
exq ( dyads ( o , r 1 , r2 ), m, q )  = 
prog ( nextmemaddr ( m ) , 
storer (appl yd op( 

o,  fetchr(rl, q), fetchr(r2, q) ) , r2, q) ) ; 
exq(dyadsi (o, V, rl )m, q)  = 
prog(nextmemaddr(m) , 

store(applydop(v, fetchr(rl, q) ) , rl,q) ) ; 
exq(dyad (o, rl , r2, r3} , m, q)  = 
prog(nextmemaddr(m), 

storer(appIydop(o, 

fetchr(rl,q) , fetchr(r2, q) ) , r3,q) ) ; 
exq ( dyad i ( o, V , r 1 , r2) , m, q )  = 
prog(nextmemaddr(m), 

storer (appl yd op(o, 

V, fetchr(rl,q) ), r2,q) ) ; 
exq ( tr lads ( o , r 1 , r2, r3 ), m, q }  = 
prog(nextmemaddr(m) , 

storer(applytop(o, fetchr(rl, q) , 

fetchr(r2,q), fetchr(r3, q) ) , r3,q) ) ; 
exq ( tr 1  ads i ( o , V , r 1 , r2 ) , m, q )  = 


prog  ( nex tmeinaddr  (m) , 

storer (applytopCo, v, 

fetchr(rl,q), fetchr(r2,  q) )  ,  r2,q) ) ; 
exq ( tr .  ad ( o , r 1 , r2, r3, r4) , m, q )  = 
prog ( nextmemaddr ( m ) , 

storer ( app lytopCo, fetchr(rl, q) , 

fetchr(r2,q), fetchr(r3,q) )  ,  r4,q) ) ; 
exq ( tr iadi ( o , V , r 1 , r2, r3)  ,  m,  q )  = 
prog  ( nex  tmeinaddr  <  m ) , 

storer(applytop<o,v, 

fetchr(rl,q) , fetchr(r2,q) ) , r3,q) ) ; 
exq ( quads ( o, r 1 , r2, r3, r4 ), m, q )  = 
prog ( nextmemaddr ( m) , 

storer( apply qop<o,fetchr(rl,q), 
fetch r(r2,q), fetchr(r3, q) , 
fetchr(r4,q),r4,q) ) ; 
exq ( quad (o,rl,r2,r3,r4,r5),m,q)  = 
prog (nextmemaddr (m) , 

s to rer< apply qop(o,fetchr(rl,q), 
fetchr(r2,q),fetchr(r3,q), 
fetchr(r4,q),r5,q) ) ; 
exq(sexads(o,rl,r2,r3,r4,r5,r6),m,q)  = 
progCnextmemaddrCm), 

storer(applyqop(o, fetch r(rl, q) , 
fetchr(r2,q),fetchr(r3,q), 
fetchr(r4,q),fetchr(r5,q) , 
fetch(r6,q),r6,q)); 

exq(sexad(o, rl, r2, r3, r4, rS, r6, r7) ,m, q)  = 
prog(nextmemaddr(m), 

storer(applyqop(o, fetchr(rl, q) , 
fetchr(r2,q),fetchr(r3,q), 
fetchr(r4,q),fetchr(r5,q), 
fetch(r6,q),r7,q) ) ; 

exqCoctads (o, rl , r2, r3, r4, r5, r6, r7, r8) , m, q)  = 
prog  <  nextmemaddr ( m ) , 

storer (applyqopCo, fetchrCrl, q) , 
fetchr(r2,q), fetchr(r3,q), 
fetchr(r4,q) ,fetchr(r5,q) , 
fetch(r6,q) , fetchrC  r7, q) , 
fetchr(r8, q) , r8, q) ) ; 

exqCoctadCo, rl, r2, r3, r4, r5, r6, r7, r8, r9) , m, q)  = 
prog(nextmemaddr(m), 

storer(applyqop(o, fetch r( rl, q) , 
fetchr(r2,q) , fetchr(r3, q) , 
fetchr(r4,q),fetchr(r5,q), 
fetch(r6,q) , fetchr(r7, q) , 
fetchr(r8,q), r9,q) ) ; 
exq (mov i_m ( V , ml ) , m , q )  = 
prog (nextmemaddr (m) , 
storem ( v , ml , q ) )  ; 
exq ( mov i_pcr ( V , i ) , m , q )  = 
prog ( nextmemaddr ( m ) , 


storen)(v,offset(i,iD),q)  }  ; 
exq(movi_r  ( V, r ) ,  m,  q)  = 
prog (nextmemaddr (m) , 
storem ( v, r , q) ) i 
exq  (mov i__r  i  <  V ,  r  )  ,  m,  q )  = 
prog ( nextmemaddr (m) , 

storem ( V , atomof memaddr (fetchr(r,q),q)) 
exq ( mov i_r 1 d ( V ,  r  ,  n )  ,  m,  q )  = 
prog (nextmemaddr (m) , 
storemCv, of f set ( 

n, atomof memaddr (fetchr(r,q),q)); 
exq  (mov  i__r  idn(  V,  r  ,  1 1 ,  12) ,  m,  q)  = 
prog ( nextmemaddr (m) , 

storem(v,offset(i2,  indi.'( 
ll,atomofmemaddr(fetchr(r,q),q) ) ; 

exq(mov_m_m(ml , m2) , m, q)  = 
prog ( nextmemaddr ( m) , 

storem(fetchm(ml,q),m2,q) ) ; 
exq ( mov_m_r ( ml , r ) , m , q )  = 
prog ( nextmemaddr (m) , 

storem ( f etchm(ml , q) , r , q) ) ; 
exq ( mov_m_r i(ml,r),m,q)  = 
prog ( nextmemaddr ( m ) , 

storem(fetchm(ml,q), 
atomof memaddr(fetchr(r, q) ,q) ) ; 
exq(mov_m_r id (ml , r ,  n) , m, q)  = 
prog(nextmemaddr(m), 

storem(fetchm(ml,q),offset( 
n,atomofmemaddr(fetchr(r,q),q) ) ; 
exq(mov_m_r idn(ml , r,il,i2),m,q)  = 
prog(nextmemaddr(m), 

starem(fetchm(ml,q),offset( 12, indir( 

11, atomofmemaddr(fetchr(r,q),q)  )  ; 

exq(mov_pcr_pcr ( 1 1 , 12) , m, q)  = 
prog ( nextmemaddr (m), 

storem (fetchm(offset(il,m),q), 
of f set( 12, m) , q) ) ; 
exq (mov_pcr_r  ( i 1 , r ) , m, q )  = 
prog(nextmemaddr(m), 

storem(fetchm(offset(il,m),q), r,q)  )  ; 
exq ( mov_pcr_r 1 ( 1 1 ,  r ) , m,  q )  = 
prog(nextmemaddr(m), 

storem( fetchm(offset( 1 1 , m)  ,  q)  , 
atomof memaddr (fetchr(r,q),q)); 
exq (mov_pcr_r id ( 1 1 , r , 12)  ,  m,  q )  = 
prog(nextmemaddr(m) , 

storem(fetchm(offset( 11, m) , q)  ,  offsetC 

12, atomofmemaddr(fetchr(r,q)  ,q) )  ; 
exq (mov_pcr_r idn (il,r,n,i2),m,q)  = 

prog(nextmemaddr(m) , 


storem(fetchin(offset(  il,  m)  ,  q)  ,offset(  i2, 
ind 1 r ( n,  atomof memaddr (fetchr(r,q),q)); 

exq (inov_r_ni (  r  1 ,  ml )  ,  m,  q )  = 
progCnextmemaddr (m) , 

storem(fetchr(rl,q>,ml,q) ) ; 
exq(mov_r_pcr ( rl , i ) , m, q)  = 
prog(nextmemaddr(m), 

storem(fetchr(rl,q),offset(i,m),q)); 
exq ( mov_r_r ( r 1 , r2 )  ,  m ,  q )  = 
prog (nextmemaddr (m) , 

storem(fetchr(rl,q), r2,q) ) ; 
exq ( mov_r_r i ( rl , r2 ) , m, q )  = 
prog ( nextmemaddr ( m ) , 

storem(fetchr(rl,q), 
atomof memaddr (fetch r(r2,q),q) ) ; 
exq (mov_r_r i d ( r 1 , r2, n ) , m, q )  = 
prog ( nex  tmemadd  r ( m ) , 

storem(fetchr(rl,q),offset( 
n, atomof memaddr (fetch r(r2,q) ,q) ) ; 
exq(mov_r_ridn(rl, r2, il, i2),m,q)  = 
pr og ( nextmemaddr ( m ) , 

storem(fetchr(rl,q),offset(i2,lndir( 
il,atomofmemaddr(fetchr(r2,q),q) ) ; 

exq ( mov_r i_m ( r 1 ,  ml ) , m , q)  = 
prog(nextmemaddr(m), 

storem(fetchm(atomofmemaddr(fetchr(rl,q)  ,q)  , 
ml , q) )  ; 

exq  ( mov_r  i  jjcr  (  r  1 ,  i  )  ,  m,  q )  = 
prog ( nextmemaddr (m ) , 

stor em ( fetchm (atomof memaddr (fetchr(rl,q),q), 
offset(i,m),q)); 
exq(mov_r i_r ( rl , r2) , m, q)  = 
prog ( nextmemaddr ( m ) , 

storer(fetchm ( atomof memadd  r (fetchr(rl,q),q), 
r2, q) )  ; 

exq(mov_ri_ri(rl,r2),m,q)  = 
pr og ( nextmemaddr ( m ) , 

storem(fetchm ( atomof memaddr (fetchr(rl,q),q), 
atomof memaddr (fetchr(r2,q) ) ,q) ) ; 
exq ( mov_r i _r i d ( r 1 ,  r2, n ) , m, q )  = 
prog (nextmemaddr (m) , 

storem( fetchm (atomofmemaddr ( fetchr ( rl , q) , q) , 
offset(n, atomofmemaddr (fetchr(r2,q) ) ,q) ) ; 
exq(mov_ri_ridn(rl,r2, II, i2),m,q)  = 
prog(nextmemaddr(m) , 

storem(fetchm (atomofmemaddr ( fetchr ( r 1 , q) , q) , 
offset(i2, indir( 

il,atomofmemaddr(fetchr(r2,q) ) ),q)  )  ; 
exq(mov_r id_m( r 1 ,  i 1 , ml ) , m, q )  = 


prog  <  nextmemaddr (m ) , 

storetn(fetchm(offset(il, 

atomof memaddr (fetchr(rl,q) )),q),ml,q) )  ; 
exq ( mov_r  i d_pcr ( r 1 , i i2>  ,  m ,  q )  = 
prog ( nextmemaddr (m) , 

storem(fetchm(offset(  il, 
atomof memaddr (fetchr(rl,q))), 
of f set( 12, m) , q) ) ; 
exq(mov_rid_r(rl,n,r2),m,q)  = 
prog ( nextmemaddr (m ) , 

storer(fetchm(offset(n, 

atomof memaddr (fetchr(rl,q) ) ) ,q) , r2,q) ) ; 
exq (mov_r i d_r i ( r 1 , i , r2)  ,  m,  q )  = 
prog (nextmemaddr (m) , 

s  torem ( f etchm (offsetC i, 
atomofmemaddr(fetchr(rl, q) ) ) ,q) , 
atomofmemaddr(fetchr(r2,q) ) ,q)  ) ; 
exq(mov_rid_rid(rl,  11, r2,  ll),m,q)  = 
prog(nextmemaddr(m), 

s torem ( f etchm (offset(ll, 
atomof memaddr (fetch r(rl,q))),q), 
offset(il, atomof memaddr (fetchr(r2,q) ) ,q) ) ; 
exq(mov_rl d_r ldn(rl,r2,ll,12,13),m,q)  = 
prog (nextmemaddr (m), 

storem(fetchm(offset( 11, 
atomofmemaddr(fetchr(rl, q> ) ) , q) , 
offset(13, lndlr( 

12,atomofmemaddr(fetchr(r2, q) ) ) ) , q) ) ; 

exq(mov_rldn_m(rl,n, ll,ml),m,q)  = 
prog(nextmemaddr(m), 

storem(fetchm(offset( 11, 

1 nd 1 r  <  n , atomof  memaddr ( 
fetchr(rl,q)))),q),ml,q)); 
exq(mov_rl  dn_pcr (rl,n,ll,12),m,q)  = 
prog ( nextmemaddr ( m ) , 

storem( f etchm ( of f set (11, 

Ind 1 r ( n, atomof memaddr (fetchr(rl,q) ) ) ),q), 
of  f set ( 1 2, m ) , q ) )  ; 

exq(mov_rldn_r(rl, 11, 12,r2),m,q)  = 
prog(nextmemaddr(m) , 

storer ( f etchm (offset( 12, 
lndlr(ll, atomof memaddr ( 
fetchr(rl,q)))),q),r2,q)); 
exq(mov_rldn_rl (rl, 11, 12,r2),m,q)  = 
prog(nex  tmemadd  r ( m ) , 

storem(fetchm(offset( 12, 

1 nd 1 r ( 1 1 , atomof  raemadd  r (fetchr(rl,q) ) ) ), q), 
atomof memaddr (fetchr(r2,q) ) ,q) )  ; 
exq ( mov_r 1 dn_r ld(rl,ll,12,r2,13),m,q)  = 
prog(nextmemaddr(m)  , 

storemC  fetchm(offset( 12, 


indirdi,  atomof  memaddr  (fetchr(rl,q)  )  )  ),q) 
offset(i3, atomof memaddr (fetchr(r2,q) ) , q) ) 
exq  ( mov_r  idn_r  idn  = 

prog ( nex tmemaddr ( m ) , 

storem(fetchm(offset(i2, 

i nd i r ( i 1 . atomof memaddr (fetchr(rl,q) ) ) ), q) 
offset(i4, indir( 

13,  atomof memaddr (fetchr(r2,q) ) ) ) ,q) ) ; 
exq (push_i ( V ,  s )  ,  m,  q )  = 
prog ( nex  tmemaddr ( m ) , 
pushstk ( V, s, q) ) ; 
exq(push_m(ml , s ) , m, q)  = 
prog (nex tmemaddr (m) , 

pushstk<fetchm<ml,q),s,q>  > ; 
exq (push_pcr ( 1 , s ) , m, q )  = 
prog ( nex  tmemaddr ( m ) , 

pushstk(fetchm(offset(i,m),q),s,q)); 
exq ( push_r ( r  ,  s )  ,  m,  q )  = 

prog(nextmemaddr(m), 

pushstk(fetchr(r,q),  s,q) )  ; 
exq< push_r  i < r , s )  ,  m,  q)  = 
prog ( nex tmemaddr (m) , 

pushstk (atomof memaddr (fetchr(r,q) ),s,q) )  ; 
exq ( push_r i d ( r ,  n,  s )  ,  m,  q )  = 
prog (nex tmemaddr ( m ) , 

pushstk ( fetchm ( of f set ( n, 
atomof memaddr ( f etchr (r,q))),q),s,q)); 
exq( push_r 1 dn( r ,  i 1 ,  12,  s ) ,  m,  q )  = 
prog (next memaddr (m), 

pushstk(fetchm(offset( 12, lndir( 1 1, 
atomof memaddr (fetchr(r,q)))),q),s,q)); 
exq ( pop_x ( s )  ,  m,  q )  = 

prog(nextmemaddr(m), 
popstk ( s , q ) ) ; 
exq ( pop_m ( s ,  ml )  ,  ra,  q )  = 
prog(nextmemaddr(m)  , 

popstk(s,storem(topstk(s,q)  ,ml,q) ) ) ; 
exq ( pop_pcr ( s ,  1 )  ,  m,  q )  = 
prog(nextmemaddr(m), 

popstk(s, storem(topstk(s,  q)  , 
offset(l,m),q))); 
exq (pop_r ( s ,  r ) ,  m,  q )  = 

prog ( nex tmemaddr ( m ) , 

popstk(s,storer(topstk(s,q),r,q)))),m,q); 
exq ( pop_r 1 ( s  ,  r )  ,  m,  q )  = 
prog(nextmemaddr(m), 

popstk(s, storem(topstk(s, q) , 
atomof memaddr (fetchr(r,q) ) ,q) ) ) ; 
exq ( pop_r 1 d ( s ,  r  ,  n )  ,  m,  q )  = 
prog(nextmemaddr(m) , 

popstk(s, storem(topstk(s, q) , offset(n, 
atomofmemaddr(fetchr(r,q) ) ),q) ) ) ; 


exq ( pop_r Idn ( s ,  r ,  i 1 ,  12) ,  m,  q )  = 
prog (nextmemaddr (m) , 

popstk(s,storem(topstk(s,q),offset(i2, 
i ndi r ( 1 1 , atomof memaddr (fetchr(r,q))}),q))); 
exq ( nop, m,  q )  = 

prog (nextmemaddr (m) ,  q)  ; 
exq( stop, m, q)  = 

prog(m,q}  =  q; 
exq( jmpCml ) , m, q)  = 
progCml , q)  ; 
exq( jmp_i  (ml ) , m, q)  = 

prog (atomof memaddr (fetchm(ml,q}),q>; 
exq( jmp_r ( r ) ,  m,  q)  = 

prog(atomofmemaddr(fetchr(r,q) >,q) ; 
exq(bra(n) , m, q)  = 

prog(offset(n, nextmemaddr (m) ) , q) ; 
exq ( bra_r ( r )  ,  m,  q )  = 

prog(offset(atoraofint(fetchr(r,q)), 
nextmemaddr (m) ) , q) ; 
exq( if (o, rl , r2, ml ) , m, q)  = 

prog(cond(appIyrop(o,fetchr(rl,q),fetchr(r2,q)) 
ml , nextmemaddr (m) ) , q) ; 
exq ( 1 f i ( o, r , V , ml ) , m, q )  = 

prog(cond(applyrop(o,fetchr(r,q),v, 
ml,nextmemaddr(m)),q): 
exq ( i f te ( o, r 1 , r2, ml , m2) , m, q )  = 

prog(cond(applyrop(o, fetchr(rl, q) , fetchr (r2, q) , 
ml , ro2) , q )  ; 

exq ( 1 f te 1 ( o , r , V, ml , m2) , m, q )  = 

prog(cond(applyrop(o, fetchr(r, q) , v,ml,m2) , q) ; 

exq( if_pcr (o, rl , r2, n) , m, q)  = 

prog(cond(applyrop(o,fetchr(rl,q),fetchr(r2,q), 
of  f  set ( n, nextmemaddr (m) ),nextmemaddr(m) ) ,q) ; 
exq ( 1 f 1 _pcr ( o , r , V , n ) , m, q)  = 

prog(cond(applyrop(o,fetchr(r,q),v), 
of  f  set ( n, nextmemaddr (m)),nextmemaddr(m)),q) ; 
exq ( i f te ( o , r 1 , r2, i 1 , 12) , m, q )  = 

prog ( cond (applyrop(o, fetchr(rl, q) , fetchr(r2, q) , 
offset(ll, nextmemaddr ( m ) ) , 
of f set ( 12, nextmemaddr ( m ))), q ) ; 
exq ( 1 f tel ( o, r , V , ml , m2 ) , m, q )  = 

prog ( cond (applyrop(o, fetchr(r, q) , v)  , 
offset( il,nextmemaddr(m) ) , 
offset(12,nextmemaddr(m))),q) ; 
exq ( tes t ( o , r 1 , ml ) , m, q )  = 

prog(cond(applybop(o, fetchr(rl, q) ) , 
ml , nextmemaddr ( m ) ) , q) ; 
exq ( testm ( o , m2 , ml ) , m, q )  = 

prog(cond(applybop(o,fetchm(m2,q)), 
ml,nextmemaddr(m) ) ,q) ; 
exq ( tes te ( o , r 1 , ml , m2 ) , m, q )  = 


prog(cond(applybop(o,fetchr(rl,q)), 
ml , m2) , q) ; 

exq ( testme ( o, m3, ml , m2) , m, q)  = 

prog ( cond (app 1 ybop ( o, f etchm ( m3, q ) ) , 
ml , m2) , q) ; 

exq ( test_pcr ( o, r 1 , n) , m, q)  = 

prog( cond (app lybop(o, fetchr(rl,q) ) ; 
offset(n, nextmemaddr (m) ) , 
nextmemaddr  <m) ) , q) ; 
exq ( testm_j)cr  ( o,  m2,  n )  ,  m,  q )  = 

prog (cond (app 1 ybop ( o, f etchm ( m2, q ) ) ; 
offset(n, nextmemaddr (m) ) , 
nextmemaddr (m) ) , q) ; 
exq( teste_pcr (o, rl , 1 1 , 12) , m, q)  = 

prog ( cond (app 1 ybop( o, f etchr ( r 1 , q ) ) ; 
offset(il, nextmemaddr (m) ) , 
offset(i2,  nextmemaddr (m) ) ) , q) ; 
exq ( testme_pcr ( o , m3, i 1 , 12) , m, q)  = 

prog ( cond ( app 1 ybop (o, f etchm (m3, q) ) ; 
offset( 11, nex tmemaddr ( m) ) , 
offset( 12, nex tmemaddr (m) ) ) , q ) 
exq ( jsr (ml , s ) , m, q)  = 
prog(ml,pushstk( 

va 1  of memaddr ( nextmemaddr ( m ) ) , s , q ) ) ; 
exq( jsr_l (ml , s ) , m, q)  = 

prog(atomofmemaddr(fetchm(ml, q) ) , 
pushstk(val of memaddr ( nextmemaddr (m ) ) , s , q ) ) ; 
exq(jsr_l(rl,s),m,q)  = 

prog ( atomof memaddr (fetchr(rl,q)), 
pushstk(valofmemaddr(nextmemaddr(m) ) ,  s,  q) ) ; 
exq (bsr ( n, s ) , m, q )  = 

prog(offset(n, nextmemaddr (m) ) , 
pushstk ( va 1  of memaddr (nex  tmemaddr ( m ) ) , s , q ) ) ; 
exq(bsr_r(r,s),m,q)  = 

prog(offset(atomoflnt(fetchr(r,q)), 
nextmemaddr (m ) ) , 

pushstk(vaIofmemaddr(nextmemaddr(m)),s,q)); 
exq ( r ts ( s } , m, q )  = 

prog(atomofmemaddr(topstk(5,q} )  ,  popstk(s,q) )  ; 
exq ( open ( s ), m, q )  = 

prog(nextmemaddr(m), openf 1 1 e ( 

atomof  str . char(topstk(s, popstk(s, popstk(s, 
popstk ( s , q ) ) ) )  ) , 

a tomof  f ile(topstk(s,popstk(s,popstk(s,q)) ) ) 
atomoflnt(topstk(s,pop5stk(5,q) )  ), 
atomoflnt(topstk(s,q), 
popstk ( s , q ) )  )  ; 
exq ( c 1 ose ( s ) , m, q )  = 

prog(nextmemaddr(m) ,ciosefi le( 
atomoffl le( topstk(s, q) ) , 
popstk ( s , q )))  ; 
exq ( read ( s ), m, q )  = 
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prog  ( nex  tmemaddr  (m),storein(infile( 

atomof f i le(topstk(s,popstk(s,q) ) ) , 
popstk ( s, q) } , 

atomof memad dr (topstk(s,popstk(s,q)), 
pops tk ( s , q } ) ) ; 
exq(write(s ) , m, q)  = 

prog (nex  tmemaddr (m),outfl le(fetchm( 

atomof memad dr (topstk(s,popstk(s, q) ) ) 
pops tk ( s , q ) ) ; 
atomof f i le(topstk(s,q) ), 
popstk ( s , q ) ) ) : 


end  am ; 


APPENDIX  B;  COMPLETE  SPECIFICATION  OF  A  SUBSET  OF 


THE  ABSTRACT  PROCESSOR 


Resource  intructions  Is 


Extension  of 
nature  1 , 
integer , 
memaddress , 
regaddress , 
stkaddress , 
operatorc lasses, 
i ntruct i on type, 
typing 

Operands 

Operators 

monad:  mop, regaddr , regaddr  ->  instr; 

dyad:  dop, regaddr, regaddr, regaddr  ->  instr; 

triad:  top, regaddr , regaddr , regaddr , regaddr  ->  in< 

mov_m_r :  memaddr , regaddr  ->  instr; 

mov_r_m:  regaddr , memaddr  ->  instr; 

mov_r_r :  regaddr , regaddr  ->  instr; 

push_r:  regaddr , stkaddr  ->  instr; 

pop_r:  stkaddr , regaddr  ->  instr; 

jmp_r:  regaddr  ->  instr; 

if:  re  1  op, regaddr , regaddr , memaddr  ->  instr; 
jsr:  memaddr , stkaddr  ->  instr; 
rts:  stkaddr  ->  instr; 

Properties 
end  intructions; 


Resource  amstate  is 

Extension  of 
boo  1 ean , 
natura 1 , 
integer , 
str ( character ) , 
memaddr ess , 
regaddress , 
files, 

identi f iers, 
typing 


static 
Operands 
state ; 

Operators 

fetchm:  memaddr , state  ->  val; 
fetchr;  regaddr , state  ->  val; 
storera:  va 1 , memaddr , state  ->  state; 
storer:  va 1 , regaddr , state  ->  state; 
topstk:  stkaddr , state  ->  val; 
pushstk:  va I , stkaddr , state  ->  state; 
popstk:  stkaddr , state  ->  state; 
initam:  ->  state; 

inltstk:  stkaddr , state  ->  state; 
active:  memld,state  ->  bool; 

Properties 

topstk ( s , ini tstk ( s ) )  is  undefined; 
popstk ( s , ini tstk < s ) )  is  undefined; 
popstk ( s, ini tam( ) )  is  undefined; 
stateaxiomlm, memaddr)  ; 
stateaxiomCr, regaddr)  ; 

topstk ( s ( pushstk ( V, s , q ) )  =  v; 
popstk < s < pushstk ( V, s , q ) )  =  q; 
act i ve (m, ini  tarn () )  -  false!); 
act i ve < m, storer ( V , r , q ) )  =  active(m,q); 
active (m, storemC V, a, q) )  ~  active(m,q>; 
act ive <m, i nl tstk ( s , q ) )  =  active(m,q); 
act i ve < m, pushstk ( V , s , q )  =  actlve(m,q); 
activeCm, popstk (s, q)  =  active(m,q>; 
if  active(m,q)  =  false!) 
then 

f etchm ! of f set ! n, m ) , q )  is  undefined; 
end i f ; 

if  active!m,q)  =  false!); 
then 

storem ! V , of f set !n, m ) , q)  is  undefined; 
end i f ; 

if  1  tint !n, ntol !n2) )  =  true!) 
then 

offset!n,offset!nl,startmeraaddr! 

1  a  1  1 oc ! n2, q ) ) ) )  = 
offset!sumint!n,nl), 
startmemaddr! lal Ioc!n2,q) ) ) ; 

else 

offset!n,offset!nl, startmemaddr! 

1  a  1 1 oc ! n2, q ) ) ) )  is  undefined; 

end i f ; 

i nd i r ! zeronat ! ) , m )  =  m; 

if  whattype ! fetchm ! ind i r ! n, m ), q )  =  typememadd r  !  ) 


ind i r ( succnat ( n ) , m )  = 

atomof memaddr ( f etchm (indir(n,m),q)) 

e  1  se 

indi r ( succnat (n ), m)  is  undefined; 
endi f ; 

Dynamic 

Entry  Places 

req_f etchm ( net  I abe 1 ) [ memaddr . state ] ; 
req_s torem ( net  1 abe 1 ) C  va 1 . memaddr . state  1  ; 

req_f etchr ( net  1 abe 1 ) C  regaddr . state ] ; 
req_storer ( net  1 abe 1 ) C  va I . regaddr . state  1 ; 

req_topstk (net  1 abe 1 ) C  s tkaddr . state ] ; 
req_pushstk (netabel ) Cval ,stkaddr. state! ; 
req_popstk (net  1 abe 1 ) C  stkaddr . state  ]  ; 
req_lni tstk(netlabel ) Cstkaddr. state] ; 

req_ini tam( ) C  ] 

Exit  Places 

avail _f etchm (netlabel )Cval ); 
aval l_storem( netlabel ) Estate] ; 

avail _fetchr( netlabel )Eval ]; 
aval l_storer(netlabel ) Estate] ; 

aval l_topstk(netlabel ) Eval ] ; 
avail _pushstk ( netlabel ) Estate] ; 
avail _pops tk (netlabel ) Estate] ; 
aval l_initstk(netlabel ) Estate] ; 

aval l_initamEstate] ; 

Internal  Places 

access_ava i 1 E ] ; 

f etchra_f or (netlabel)E]; 

f etchm_act ivatedEmemaddr. state]; 

f etchm_comp letedEval ] ; 

storem_f or ( net  1 abe 1 ) E ] ; 

storem_act i vatedEval .memaddr. state] ; 

storem_compl etedE state] ; 

access_ava 1 1 E ] ; 
fetchr_for(netlabel ) E ] ; 
fetchr_activatedEregaddr. state]; 
f etchr_comp letedEval ] ; 
storer_for(netlabel )E]; 
storer_activatedEval . regaddr. state]  ; 
storer_completedEstate] ; 


accessk_avai 1 C ] ; 
topstk_f or (netlabel>C]; 
topstk_actlvatedC  s tkaddr . state ] ; 
topstk_conp 1 eted [ va 1 ] ; 
pushstk_for(netl abe I ) [ 1 ; 
pushstk_actl vatedC  val.stkaddr. state] ; 
pushstk_coinp  let  ed  (state! ; 
popstk_for(netlabel >(]; 
popstk_activatedCstkaddr. state]; 
popstk_coinp letedCstate]  ; 

Ini tstk_f or  <netlabel)Cl; 

ini tstk_act i vated C  stkaddr . state ] ; 

1 ni tstk_comp 1 etedC state]; 


Initial  State 

=>  accessm_aval I [ ] ; 

=>  accessr_ava i 1 C ] ; 

=>  accessk_aval 1C]; 

Transitions 

act_fetchin:  C  tnemaddr .  state  ],(  ]  ->  Cmetnaddr  .  s  tate  ] ,  (  ] 
per f orm_f etchm :  Cmemaddr. state]  ->  C va 1  ]  ; 
f  I  n i sh_f etchm :  [val],[]  ->  [val],C]; 
act_storem;  C va 1 . memaddr . state ], C ]  -> 

[ va 1 . memaddr . state], (]; 

per f orm_s torem :  C va 1 . memaddr . state ]  ->  (state]; 
f i ni sh_storem ;  (state], (]  ->  (state], (]; 

act_fetchr:  ( regaddr . state ],( ]  -> 

Cregaddr. state],  (]; 

per f orm_f etchr :  ( regaddr . s tate ]  ->  Cval]; 
f inlsh_fetchr :  Cval],(]  ->  Cval],C]; 
act_storer:  ( va 1 . regaddr . s tate ],( ]  -> 

Cval . regaddr. state], ( ] ; 

perf orm_storer ;  ( va 1 . regaddr . state ]  ->  (state]; 
f inlsh_storer :  (state], (]  ->  (state], (]; 

act_topstk:  C s tkaddr . state  ],(  ]  -> 

(stkaddr. state], (]; 

per f orm_topstk :  ( stkaddr . state ]  ->  Cval]; 
f ini sh_topstk :  (val],C]  ->  Cval],!]; 
act_pushstk;  C va 1 . s tkaddr . s ta te ],( ]  -> 

(val . stkaddr. state], (  ]  ; 

per f orm_pushstk :  ( va 1 . stkaddr . state  ]  ->  (state]; 
f I ni sh_pushs tk ;  (state], (]  ->  (state],!]; 
act_popstk:  C s tkadd r . s tate ] , C ]  -> 

(stkaddr. state], (  ]  ; 

per f orm_popstk :  C s tkaddr . state  ]  ->  (state]; 
f i n i sh_pops tk :  (state],!]  ->  (state],!]; 


act_initstk:  [ stkaddr . state ],[ ]  -> 

C stkaddr . state ] , []; 

perf orm_inI tstk ;  C stkaddr. state]  ->  [state]; 
f Inish_inl tstk :  [state], []  ->  [state], []; 

perf  orm_l  ni  tain :  []  ->  [state]; 

Properties 

act_f etchm ( req_f etchm ( I ) [m. q ] ,  accessm_ava i 1 [ ] )  => 
f  etchm_f  or  (!)[],  f  etchin_act i  vated[m.q]; 
perf  or  in_f  etchm  (  f  etchm_acti  vated[m.  q] )  => 
f etchm_comp 1 eted[ v ] ; 

f ini sh_f etchm ( f etch_comp 1 eted [ v ] ,  f etchm_f  or (!)[]) 

=>  avai l_f etchm( I ) [v] ,  accessm_avai 1 [ ] ; 
act_storem( req_storem( 1 ) [ V.  m.  q] ,  accessm_ava i I [ ] )  => 
storem_for  < 1 ) [ ] ,  storem_activated[ v. m. q] ; 
per f orm_storem ( storem_activated[ v. m. q] >  => 
storem_comp 1 e ted [ q ] ; 
f ini sh_s torem ( stor em_comp 1 eted [ q ] , 
storem_f or ( 1 ) [ ] )  => 

avail _storem( 1 ) [q],  accessm_avai 1 [ ] ; 

act_f etchr ( req_f etchr < 1 ) [ . q ] ,  accessr_avai 1 [ ] )  => 
fetchr_for( 1 )[], f  etchr _act i vated[.q]; 
perform_f etchr [fetchr_activated[.q])  => 
fetchr_completed[v] ; 

f 1 ni sh_f etchr ( f etch_comp leted[v],  fetchr_for(l)[]) 

=>  avai 1 _f etchr ( 1 )[ V ] ,  accessr_avai I [ ] ; 
act_storer(req_storer( 1 ) [v.  .  q],  accessr_avai 1 [ ] ) 

=>  storer_f or ( I ) [ ] ,  storer_act i vated [ v . . q ] ; 
per f orm_storer ( storer_acti vated [ v . . q ] )  => 
storer_compIeted[q]; 
f i n I sh_s tor er ( s  tor er_comp 1 eted [ q ] , 

storer_for(l)[])  =>  avai 1 _storer ( I ) [ q ] , 
accessr_avai 1 [ ] ; 

act_tops tk ( req_tops tk ( 1 ) [ s .  q ]  ,  accessk_ava i 1 [ ] )  => 
topstk_for( I ) [ ],  topstk_activated[s. q] ; 
perform_topstk( tops  tk_act ivated[s.q])  => 
topstk_compIeted[v] ; 

finish_topstk(topstk_completed[v], topstk_for( 1 ) [ ]  => 
avai l_topstk( 1 ) [v] ; 

act_pushstk ( req_pushs tk (l)[v.s.q],  accessk_avail[]) 

=  >  pushstk_f or ( 1 ) [ ] ,  pushs tk_act i va ted [ v . s  .  q ] ; 
per  f orm_pushs tk (pushstk_activated[s.q])  => 
pushstk_comp leted[ql]; 

fin i sh_pushs tk ( pushs tk_comp leted[ql ],pushstk_for( 1 )  [  ] 
=>  ava i 1 _pushs tk < I ) [ ql ] ; 

act_pops tk ( req_pops tk (l)[s.q],  accessk_avail[])  => 
popstk_for( 1 ) [ ],  popstk_act i vated [ s . q ] ; 
per f orm_pops tk (popstk_activated[s.q])  => 
popstk  comp  1 eted [ qi ] ; 


f i ni sh_pops tk ( pops tk_comp leted[ql],popstk_for(I)C]  => 
avail  _popstk ( 1 ) C  ql 3 ; 

act_ini tstk ( req_lni tstk ( I ) C s. q] ,  accessk_ava i 1 C ] )  => 
ini tstk_f or ( 1) [ ] ,  ini tstk_act i vated [ s .  q] ; 

per f orm_ini tstk ( ini tstk_act i vatedCs.q])  => 
ini tstk_comp letedCql] ; 

f ini sh_ini tstk( ini tstk_comp letediql],  ini ts tk_f or ( I ) C ] 
=>  avai 1 _ini ts tk ( 1 ) [ ql ] ; 

per f orm_ini tam ( req_ini tamC ] )  =>  avai 1 _i ni tamC state ]  ; 
end  amstate; 


Resource  am  is 

Extension  of 

memaddr ess , 
intructi on type , 
typing, 
amstate 

Operands 

prog:  memaddr , state  ->  state; 

cond :  va 1 , memaddr , memaddr  -  memaddr; 
exq:  instr , memaddr , state  ->  state; 

Operators 

prog<m,q)  =  exq ( atomof i ns t r ( f e tchm ( m , q ) ) , m , q ) ; 
cond ( va 1  of boo  1 ( true (), m, m2> )  -  m; 
cond ( va 1  of bo  1  I ( f a  1 se ( ) , m, m2 } >  =  m2; 

Properties 

exq < monad ( o , r , r2 ), m , q  )  = 
prog(nextmemaddr(m), 

storerCappl ymop ( o,fetchr(r,q>>, 
r2, q) )  ; 

exq ( dyad ( o , r , r2, r3 ), m, q )  = 
prog ( nextmemaddr (m) , 

storer(applydop(o, 

fetchr(r,q), fetchr(r2,q) ) , r3,q) ) ; 
exq ( tr iad ( o , r , r2, r3 , r A ) , m, q)  = 
prog ( nextmemaddr ( m ) , 

storer(applytop(o, fetchrCr, q) , 

fetchr(r2,q), fetchr(r3,q) ) , r4, q)  )  ; 
exq(mov_m_r (m,  r ) , m, q)  = 
progCnextmemaddrCm), 

storem(fetchm(m,q),r,q) )  ; 
exq(mov_r_m( r  ,  m)  ,  m,  q)  = 
prog(nextmemaddr(m)  , 

storem(fetchr(r,q),m,q) )  ; 


exq ( mov_r_r ( r , r2 ) , m, q)  = 
prog  (nextniemaddr  (m) , 

storem(fetchr(r,q) , r2,q) ) ; 
exq ( push_r ( r , s ) , m, q )  = 
prog(nextmemaddrCm) , 

pushstk(fetchr(r,q), s,q) ) ; 
exq ( pop_r ( s , r ) , m, q )  = 

prog ( nextmemaddr ( m ) , 

popstk(s, storer (topstk(s, q> , r, q) ) ) ) , m, q) ; 
exq ( jmp_r ( r )  ,  m,  q )  = 

prog  (atomof  niemaddr  (fetchr(r,q)),q)  ; 
exq( if (o, r , r2, ml ) , m, q)  = 

prog(cond(applyrop(o,fetchr(r,q),fetchr(r2,q)), 
ml ,  nextmemaddr  < m ) ) , q) ; 
exq( jsr (m, s) , m, q)  = 
prog(m,piJshstk( 

va 1  of memaddr ( nextmemaddr ( m ) ) , s , q ) ) ; 
exq(rts(s),m,q)  = 

prog ( atomof  memaddr (topstk(5,q)),popstk(s,q)  )  ; 

Dynamic 

Entry  Places 

req_prog [ memaddr .state  ]  ; 

req_exq (netlabel ) Cinstr. memaddr . state] 5 
req_cond (netlabel ) Cval . memaddr . memaddr  3 ; 

Exit  Places 

avai l_exq( netlabel ) [memaddr. state] ; 

avail _cond (netlabel ) [ memaddr  3 ; 

Internal  Places 
prog_avai 1 [ 3 ; 

prog_f etch [memaddr . state] ; 
prog_instr[memaddr. state]; 
prog_per f orm[ ] 

exq_ava I  1 [ 3 ; 
exq_for(netl abe I ) [ 3 ; 

exq_monad_act ivated[state3 ; 
exq_monad_f etch[ state] ; 
exq_monad_app 1 y [ s  tate  3 ; 
exq_monad_store [ 3 ; 

exq_dyad_activated[state] ; 
exq_dyad_f etch[ state  3 ; 
exq_dyad_app 1 y [ s tate 3 ; 
exq_dyad_store[ 3 ; 


exq_tr iad_act ivatedCstatel; 
exq_tr iad_f etchC  state ] ; 
exq_tr iad_app lyCstatel; 
exq_triad_store[ ] ; 

exq_mov_r_r_act 1 va ted [ state ] ; 
exq_mov_r_r_perf orm [ s tate 3 ; 
exq_mov_r_r_storeC  3  ; 

exq_mov_r_ra_act i vated [ state  3 ; 
exq_niov_r_m_perf  ormCstate3 ; 
exq_mov_r_m_store C  3  ; 

exq_mov_m_r_act i vatedCstate3: 
exq_mov_m_r_per  f orm  C  state  3 ; 
exq_mov_m_r_store C  3 ; 

exq_push_r_act i vated C state  3  ; 
exq_push_r_perf ormC state3  ; 
exq_push_r_push C  3 ; 

exq_pop_r_act i vated  C  state  3 ; 
exq_pop_r_per form [ state  3 ; 
exq_pop_r_store [ 3  j 
exq_pop_r_popC  3  ; 

exq_jmp_r_act i vated  C  state  3 ; 
exq_jmp_r_j3er  f  orm  [  state  3  ; 
exq_jmp_r_convertingEstate3 ; 

exq_i f_activatedCstate3 ; 
exq_i f_fetch[state3 ; 
exq_i f _cond C state  3 ; 

cond_act i vated Cmemaddr. memaddr  3 ; 

Initial  State 

=  >  prog_avai 1 C  3 ; 

=  >  exq_avai I C  3 ; 

=  >  cond_avai 1 C  3 ; 

Transitions 

acti vate_prog :  C 3 , C memaddr . state 3  -> 
Cmemaddr. state3, C memaddr . state 3  ; 
get_instr_prog :  C memaddr . state  3 ,[ va 1 3  -> 
Cmemaddr. state!, Cval  3; 
perf orm_prog :  [ memaddr . state  3 , C i ns tr 3  -> 
C3,Clnstr. memaddr. state! ; 
finish_prog:  [ 3 , C memaddr . state  3  -> 

C  3 , C  memaddr . s  tate  3  ; 
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act i vate_exq_monad ;  C i ns t r • memaddr . s tate ] , [ ]  -> 
[state], Cinstr], [instr], Cinstrl, C memaddr]; 
start_exq_monad :  C state ], C regaddr ] ,  -> 

[state], [regaddr. state]; 
app 1 y_exq_monad ;  [ state ],[ operator ],[ va 1 ]  -> 

[state], [operator. val ]; 
store_exq_monad :  [ s tate ],[ va 1 ],[ opera tor ]  -> 

[ ], [val . regaddr. state]  ; 
f inish_exq_monad :  [],[ state ],[ memaddr ]  -> 

[memaddr. state] ; 

act i vate_exq_dyad ;  [ i ns tr . memaddr . s tate ],[ ]  -> 

[state], [instr], [instr], [instr],  [instr], [memaddr]  ; 
star t_exq_dyad :  [ state ],[ regaddr ],[ regaddr ]  -> 

[state], [regaddr. state], [regaddr. state]  ; 
app 1 y_exq_dyad ;  [ s tate ],[ operator ],[ va 1 ],[ va 1 ]  -> 

[state], [operator. val, val  ]; 
store_exq_dyad :  [ s ta te ] , [ va 1 ] , [ r egadd r ]  -> 

[ ], [val . regaddr. state]  ; 
f ini sh_exq_dyad :  [ ] , [ s tate ] , [ memadd r ]  -> 

[memaddr. state] ; 

act i vate_exq_t r iad :  [ i ns tr . memaddr . s tate ],[ ]  -> 

[state], [ instr],  [ instr], [ instr], [  instr], 

[instr], [ memaddr  ]  ; 

star t_exq_tr iad :  [state], [regaddr], [regaddr], [regaddr] 
[state], [regaddr. state], [regaddr], [regaddr] ; 
app I y_exq_tr iad :  [state], [operator], [val ], [val ], [val  ] 
[state ] , [ operator . va 1 . va 1 . va 1  ]  ; 
store_exq_tr i ad ;  [ s tate ],[ va 1 ],[ regaddr ]  -> 

[ ], [val . regaddr. state] ; 
f ini sh_exq_tr iad :  [],[ state  ], [memaddr ]  -> 

[memaddr. state]  ; 

act i vate_e xq_mo v_r _r :  [ i ns tr . memadd r . s tate ],[  ]  -> 

[state], [instr], [instr], [memaddr ] ; 
star t_exq_mov_r_r :  [ start ],[ regaddr ]  -> 

[state] , [regaddr. state]  ; 
store_exq_mov_r_r ;  [ s tate  ],[ regaddr ],[ va I ]  -> 

[], [val. regaddr. state]; 
f i n i sh_exq_mov_r_r :  [],[ s tate ],[ memadd r ]  -> 

[ memaddr . state] ; 

act  I vate_exq_mov_r_m :  [ i ns tr . memadd r . s tate ],[ ]  -> 

[state], [instr], [instr], [ memaddr ] ; 
star t_exq_mov_r_m :  [ start  ],[ regaddr ]  -> 

[state], [regaddr. state]  ; 
store_exq_mov_r _m :  [ state ], [memaddr ],[ va 1 ]  -> 

[ ], [val .memaddr. state]  ; 
f i ni sh_exq_mov_r_m :  [],[ s tate  ],[ memadd r ]  -> 

[memaddr. state] ; 


act i vate_exq_mov_m_r :  [ instr. memaddr. state] , C ]  • 
[state], [instr], [instr], [memaddr ] ; 
star t_exq_mov_m_r ;  [ star t ], [memaddr ]  -> 

[state], [regaddr. state] ; 
store_exq_mov_m_r :  [ s tate ] , [ r egadd r ] , [ va 1 ]  -> 

[], [val. regad dr. state]; 
f i n i sh_exq_mov_m_r :  [],[ state ],[ memaddr ]  -> 

[ memaddr . state ]  ; 

act i vate_exq_push_r :  [ i ns tr . memaddr . s tate ],[ ]  -> 

[state], [ instr], [ inestr], [memaddr] ; 
f etch_exq_push_r  :  [ s tate ],[ regaddr ]  -> 

[state], [regaddr. state] ; 
push_exq_push_r :  [ state ],[ va 1 ],[ stkaddr ]  -> 

[ ], [stkaddr. state]  ; 

f in i sh_exq_push_r :  [ ] ,  [ s tate ] , [ memadd r ]  -> 

[ memaddr . state  ]  ; 

act i vate_exq_pop_r  :  [ i ns tr . memaddr . s tate ],[ ]  -> 

[state], [ instr], [ instr], [memaddr] ; 
pop_exq_pop_r ;  [ s ta te ] , [ s tkaddr ]  -> 

[state], [stkaddr. state] ; 
s tor e_exq_pop_r :  [ state ],[ va I ],[ regaddr ]  -> 

[stkaddr], [stkaddr. state]; 
top_exq_jiop_r  :  [  stkaddr  ],[  state  ]  -> 

[], [stkaddr. state]; 

f i n i sh_exq_pop_r j  [],[ state ],[ memaddr ]  -> 
[memaddr . state  ]  ; 

act i vate_exq_jmp_r ([instr. memaddr. state], [])  -> 

[ state ],[ instr  ]  ; 

f etch_exq_jmp_r ([state], [regaddr]  -> 

[state], [regaddr. state]; 
con ver  t_exq_j  mp_r ([state], [val])  -> 

[ state ] , [ va 1 ] ; 

f i n i sh ([ state ],[ memaddr ] )  -> 

[ memaddr . state] ; 

act i vate_cond ( [ ] , [ va I . memaddr . memaddr ] )  -> 

[memaddr . memaddr ] ,  [ va 1  ]  ; 
f ini sh_cond ( [memaddr . memaddr ],[bool])  -> 

[ memaddr  ]  ; 

activate _exq_if([], [instr. memaddr. state])  -> 

[ ],  [state], [ instr], [ instr], [ instr],  [memaddr  ] 
start _exq_if([state], [regaddr], [regaddr])  -> 
[regaddr. state], [regaddr. state]; 
3^PPly_®xq_if(  [state],  [val  ],  [val  ],  [operator]  )  -> 
[state], [operator. val .val ]; 
cond_exq_if([state], [memaddr], [val ], [memaddr])  - 
[state], [val. memaddr. memaddr 1 ; 


f ini sh_exq_i fCCstate],  C  memaddr ]  -> 

[memaddr. state] ; 

Properties 

activate_prog  (prog_avai  1  [  ] ,  req_prog[ni.  q]  )  => 
prog_f etchCm. q] ,  req_f etchm( 1 1 ) Cm. q] ; 
get_i  nstr_prog( prog_act i vated  Cm.q],  avail _f etc hm(ll)[v]) 
=>  prog_instr Cm. q] ,  r eq_atomof instr ( 1 2 ) C v ] ; 
perf orm_prog (prog_instr  Cm.q], 

avai 1 _atomof ins tr ( 1 2 ) C i ] )  => 
prog_per f orm C ] ,  req_exq( 13) C i . m. q] ; 
f ini sh_prog ( prog_per f ormC ] ,  avai 1 _exq C ml . ql ] )  => 
prog_avai 1 C ] ,  req_prog Cml . ql ] ; 

act i vate_exq_monad ( exq_aval 1C], 

req_exq ( 1 ) C  monad  <o.rl.r2).m.q])  => 
exq_f  or  < 1 ) C ] ,  exq_monad_acti vated  C  q ] , 
req_operator ( 11) Cmonad(o.rl.r2) ], 
req_operandl ( 1 2) C  monad (o. r 1 . r2 ) ] , 
req_operand2 ( 1 3) C  monad ( o. r 1 . r2) ] , 
req_nextmemaddr ( 1 4) Cm] ; 
star t_exq_monad ( exq_monad_acti vated  C  q ] , 

avai l_operandl ( 1 1 ) C rl ] )  ->  exq_monad_f etchCq ] , 
req_f  etchr ( 1 5 ) C  r 1 . q ] ; 

s^PP  1  y_exq_monad  ( exq_monad_f  etchC  q  ],  avail_fetchr(15)Cv], 
avai 1 _operator ( 1 1 ) C o ] )  =>  exq_monad_app 1 y C q ] , 
req_apply_mop( 16) Co. v] ; 
store_exq_monad <  exq_monad_appl y C  q] , 

avai 1 _app 1 y_mop ( 1 6 ) C vl ] ,  avai 1 _operand2 ( 1 3 ) C r2 ] )  => 
exq_monad_store  C ] ,  req_storer (17)Cvl.r2.q]; 
f in i sh_exq_monad ( exq_monad_storeC ],  avail_storer(17)Cql], 
avai 1 _nex tmeraaddr < 1 4 ) Cml ] )  =>  ava i 1 _exq ( 1 ) C ml .  ql ] ; 

activate_exq_dyad<exq_avai 1C], 

req_exq ( 1 ) C  dyad (o.rl.r2,r3).m.q])  => 
exq_f or  < 1 ) C ] ,  exq_dyad_activatedC  q] , 
req_operator ( 1 1 ) CdyadCo. rl. r2, r3) ] , 
req_operand 1 ( 1 2) C  dyad (o.rl.r2,r3)], 
req_operand2( 1 3 ) C  dyad  <o.rl.r2,r3)], 
r eq_operand3  < 1 8 ) C  dyad (o.rl.r2,r3)], 
req_nex  tmeraaddr ( 1 4 ) C  m ] ; 
start_exq_dyad  <  exq_dyad_acti vated  C  q ] , 

avai l_operandl( 1 1) Crl]),avai l_operand2( 12) Cr2] 

->  exq_dyad_f etchCq ] , req_f etchr ( 1 5 ) C  r 1 . q ] 
req_f etch( 19) C  r2.  q] ; 

app 1 y_exq_dyad ( exq_dyad_f etchC  q ],  avail _fetchr(15)Cvl], 
avai l_operator( 1 1 ) Co] ) ,avai l_fetchr( 19) Cv2] 

=>  exq_dyad_applyCq], req_app 1 y_dop ( 16)Co.vl.v2]; 
s tore_exq_dyad ( exq_dyad_app 1 y C  q ]  , 

ava i 1 _app 1 y_dop ( 1 6 ) C v3 ] ,  ava i 1 _operand3 ( 1 8 ) C r3 ] )  => 
exq_dyad_storeC ],  req_storer( 17) Cv3. r3.q] ; 
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f ini sh_exq_dyad ( exq_dyad_store  t ],  avail _storer(17)[ql], 
avai 1 _nex tmemaddr ( 1 4 ) [ml  3 )  =>  avai 1 _exq ( 1 ) [ ml . ql ] ; 

act i vate_exq_tr iad ( exq_avai 113, 

req__exq  (  I)[triad(o.rl.r2,r3,r4).m.q])  => 
exq_f or ( 1 ) C  3  ,  exq_tr iad_act i vated [ q  3 , 
req_operator ( ll)[triad(o.rl. r2, r3) 3, 
req_operandl ( 12) [triad(o.rl. r2, r3) 3, 
req_operand2 ( 1 3) C  triad(o. rl. r2, r3) 3 , 
req_operand3 ( 18) [triad  Co. rl. r2, r3) 3, 
req_operand4 (110)ttriad(o.rl.r2,r3,r4)3, 
req_nex tmemaddr ( 1 4) Cm3 ; 
s tar t_exq_tr iad ( exq_tr iad_acti vated  C  q  3 , 

avai l_operandl ( 1 1) Crl3),avai l_operand2( 12) [r23 
avail _operand3 ( 1 3 ) C  r33 ,  -  >  exq_t r iad_fetchCq), 
req_f etchr ( 1 5 ) [ r 1 .  q  3  ,  req_f etch ( 1 9 ) [ r2.  q  3  , 
req_f etchr  <lll)Cr3.q3; 

app 1 y_exq_tr iad ( exq_tr iad_fetch[q3,  avai l_fetchr( 15) [vl3, 
avai l_operatorC 1 1) Co3) ,avai l_fetchr( 19) [v23, 
avai 1 _f etchr < 1 1 1 ) C v33  =>  exq_tr iad_app 1 y C q3 , 
req_app 1 y_top  C16)Co.vl.v2.v33; 
store_exq_tr iad ( exq_tr iad_app 1 y  C q 3 , 
avai l_apply_top( 16) C v43 ,  avai 1 _operand4 ( 1 8 ) [ r4 3 )  => 
exq_tr iad_storeC  3,  req_storer (17)[v4.r4.q3; 
f ini sh_exq_tr iad ( exq_tr iad_store  C  3,  avail ^storer(17)Cql3, 
avai 1 _nextmemaddr ( 1 4 ) [ml  3 )  =>  avai 1 _exq( 1 ) Cml . ql 3 ; 

act  i  vate_exq_mov_r__r  ( exq_ava i  1  [  3 , 

req_exq  (  l)[mov__r_r(rl,r2).m.q3)  => 
exq_mov_r_r_act i vatedCq3, 
req_operandl (11) Cmov_r_r  ( r 1 , r2) 3 , 
req_operand2 ( 12) [ mov_r_r ( r 1 ,  r2 ) 3  , 
req_nex tmemaddr ( 1 3 ) [ m  3 ; 
star t_exq_mov_r_r ( exq_mov_r_r_act ivatedCq), 
avai l_operandl ( 1 1 ) C r 1 3 )  => 

exq_mov_r  _r_per  f  ormC  q  3  ,  req_f  etchr  (  1  4  )  [  r  1 .  q  3  ; 
store_exq_mov_r_r  ( exq_mov_r_r_per  f  orm  [  q  3 , 

avai 1 _f etchr ( 1 4 ) [ V 3 ,  avai 1 _operand2 ( 1 2 ) C r2 3 )  => 
exq_mov_r_r_store[ 3  ,  req_storer  C  v  .  r2.  q  3 ; 
f i ni sh_exq_mov_r_r ( exq_mov_r_r_s  tore [ 3,  avail_storerCql3, 
ava i 1 _nex tmemaddr ( 1 3) [ ml  3 )  => 
avai l_exq( I ) Cml.qll; 

act  i  vate_exq_raov_r_m  (exq_avai  1  C  3 , 

req_exq( l)Cmov_r_m(rl,m2).m.q3)  => 
exq_mov_r_m_act ivatedCq), 
req_operand 1 ( 1 1 ) C  mov_r_m ( r 1 , m2 ) 3 , 
req_operand2 ( 12) C mov_r_m ( r 1 ,  m2 ) 3  , 
req_nex tmemaddr  < 1 3) Cm3 ; 
star t_exq_mov_r_m (exq_mov_r_m_activated[q3 , 
ava i 1 _operandl ( 1 1 ) C r 1 3 )  => 

exq_mov  r _m_per f orm C q 3 ,  req  f etchr ( 1 4 ) C r I . q 3 ; 


store_exq_mov_r_m  ( exq_mov_r_m_perf  orin[  q  ] , 

avai  1  _f  etchr  ( 1  4)  C  V 3  ,  avai  l_operand2(  12)  [nj23  )  => 
exq_mov_r_in_store C  ] ,  req_storem[  v.  m2,  q]  ; 
f ini sh_exq_mov_r_m ( exq_mov_r_m_store  C ],  avail_storemCql], 
avai l_nextmemaddr ( 13) Cml ] )  => 
avail _exq( 1 ) Cml.ql] ; 

act i vate_exq_mov_m_r ( exq_avai 111, 

req_exq( 1 ) [mov_m_r (m2, r2) .  m.  q] )  => 
exq_mov_m__r_acti  vated  Cq  ]  , 
req_operandl (11) Cmov_m_r (m2, r2) ] , 
req_operand2 ( 1 2) C mov_m_r (m2, r2 ) ] , 
req_nextmemaddr ( 1 3 ) C  m 1 ; 
star  t_exq_mov__m_r  ( exq_mov_m_r_act  i  vated C  q  1 , 
avai l_operandl ( 1 1 ) [m2] )  => 

exq_mov_m_r_perf ormC  q] ,  req_f  etchm ( 1 4 ) [ m2. q  ]  ; 
store_exq_mov_m_r (exq_mov_m_r_perf ormt  q]  , 

avai 1  _f  etchm ( 1 4 ) t V ] ,  avai 1 _operand2 ( 1 2 ) [ r2 ] )  => 
exq_mov_m_r_store [ ] ,  req_storer [ v . r2. q ] ; 
f ini sh_exq_mov_m_r (exq_mov_m_r_s tore  C ],  avaiI_storerCql], 
avai I _nex tmemaddr ( 1 3) C ml ] )  => 
avai l_exq( 1 ) Cml.ql] ; 

actl vate_exq_push_r ( exq_aval 1C], 

req_exq ( I ) C push_r ( s ,  r ) . m.  q ] )  => 
exq_push_r_act ivatedCq], 
req_operandl ( 1 1 ) C  push_r (s, r ) 1 , 
req_operand2( 12) Cpush_r  (s, r) ] , 
req_nextmemaddr ( 13) Cm] ; 
f etch_exq_push_r ( exq_push_r_act i vatedCq], 
avai 1 _operand2 ( 1 2 ) C r ] )  => 

exq_push_r_per f orm  C  q ] ,  req_f etchr ( 1 4 ) C  r  .  q ] ; 
push_exq_push_r ( exq_push_r_per f ormC  q ]  , 

ava i 1 _f etchr ( 1 4 ) [ V ] ,  avai 1 _operandl ( 1 1 ) C s ] )  => 
exq_push_r_s toreC ] ,  req_pushC  v.  s .  q ] ; 
f i ni sh_exq_push_r ( exq_push_r_store C ] ,  avail _push C  ql ] , 
avai 1 _nex tmemaddr ( 1 3 ) C ml ] )  => 
aval l_exq(l)[ml.ql]; 


act i vate_exq_pop_r (exq_avai I C  3 , 

req_exq ( 1 ) C pop_r ( s  ,  r ) . m. q] )  => 
exq_pop_r_act i vated  C  q 1 , 
req_operand 1 ( 1 1 ) C  pop_r ( s , r ) 3 , 
req_operand2 ( 1 2 ) C  pop_r ( s , r ) 3  , 
req_nex tmemaddr ( 1 3) Cm] ; 
pop_exq_pop_r ( exq_pop_r_act i vated  C  q ] , 
avai 1 _operandl ( 1 1 ) C s ] )  => 
exq_pop_r_per  f orm  C  q  3 ,  req_top ( 1 4 ) C  s . q 1 ; 
stor e_exq_pop_r ( exq_pop_r_per f orm  C  q  3 , 

avai 1 _top ( 1 4 ) C V ] ,  ava i 1 _operand2 ( 1 2 ) C r ] )  => 
exq_pop_r_s  to r e  C  s ]  ,  r eq_s torer  C  v  .  r  .  q ] ; 
top_exq_pop_r ( exqpop  r  store C s 3  ,  ava i 1  storer[ql3  => 


exq_pop_r_popC ] , req_popC  s. ql ] ; 
f I nl sh_exq_pop_r (exq_pop_r_pop£ ] ,  ava 1 1 _pop[ q2 ] , 
avai  1  _nextniemaddr  (  1 3 )  [ml  3  )  => 
avail_exq(l)[ml.q2]; 

acti vate_exq_jmp_r (exq_avai 1 C  3 , 
req_exq ( 1 ) C jmp(r ) . m. q3 )  => 
exq_jmp_r_act i vated  t  q  3 , 
req_operandl C 1 1 ) C jmp ( r ) 3 ; 
f etch_exq_jmp_r (exq_jmp_r_act i vated  Cq  3 , 
aval l_operandl ( 1 1 ) [ r3  => 

exq_jmp_r_pGrf ormCq3 , req_f etchr ( 12) [ r. q3 ; 
convert_exq_jmp_r (exq_jmp_r_perf orm[q3 , 
aval  1 _f etchr ( 1 2) C V 3 )  => 

exq_Jrap_r_convert i ng [ q3 , req_atomof memaddr ( 1 3) £  v3 ; 
f ini sh_exq_jmp_r ( exq_jmp_r_conver t ing £  q 3 , 
avai l_atomof memaddr ( t 3) £ml 3  => 
avai l_exq(I)[ml.q3; 

acti vate_cond ( cond_avai 1  £  3 , req_cond (l)£v.ml.m2  3)  => 
cond_act i vated[ml.m2  3, req_atomof boo  1 ( 1 1 ) £  v  3 ; 
f i ni sh_cond ( cond_act ivated£ml.m23, 
avai l_atomQf boo  1 ( 1 1 ) £ true( ) 3  => 
avail _cond ( 1 ) £ml 3 ; 
f ini sh_cond ( cond_acti vated £ ml . m23 , 
avai I _atomof boo l(ll)£false()3  => 
ava i 1 _cond ( 1 ) £  m2  3 ; 

activate_exq_if (exq_avai 1  £  3 , 

req__exq<  l)£if(o.rl.r2.ral).m.q3)  => 
exq_f or  < 1 ) £  3 ,  exq_i f _act i vated  £  q  3 , 
req_operator (ll)£if(o.rl.r2.ml)3, 
req_operandl (12)[if(o.rl.r2.ml)3, 
req_operand2( 13)£if(o.rl.r2.ml>3, 
req_next memaddr ( 1 4 ) £  m  3 
star  t_exq_i f (exq_i f _act i vated£q 3  , 
avail  __operandl  (  11)  £rl3,avai  l_operand2(  12)  [r23  ) 

->  exq_i f _f etch  £  q  3 ,  req_f etchr ( 1 5 ) £  r 1 . q  3 
req_f etchr ( 1 7 ) £  r 1 . q  3 ; 

®PP 1 y_exq_i f  <  exq_l f_fetch£q3,  avai l_fetchr(15)[vl3, 
avai 1 _f etchr ( 1 7) £ v23 ,  ava i 1  _operator ( 1 1 ) £ o 3 )  => 
exq_i f _app 1 y [ q  3  ,  req_app 1 y_rop( 16)[o.vl.v23; 
cond_exq_i f ( exq_i f _app 1 y  £  q3 , avai 1 _next memaddr ( 14) £  m2  3 
avail _operand3 ( 13) £ m3 3 , avai 1 _app I y_rop ( 1 6 ) £  v3 3 ,  = 

exq_I f _cond  £  q  3  ,  req_cond ( 17)£v3.m3.m2  3 ; 
f i ni sh_exq_i f ( exq_i f _cond £ q 3  ,  ava i 1 _cond C 1 7 ) £  m3  3 )  => 
avai l_exq( 1 ) £m3.q3 ; 


end  am; 
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